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in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
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Foreword 

This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

The present document supplements IEEE Standard P802. 16-2001 [1] as amended by IEEE Standard P802.16c [2], 
which shall be considered normative in its entirety, with exclusion of the Physical Layer (PHY) and profiles defined 
therein. 

The present document describes the supplemental data transport and radio control functions of the Data Link Control 
(DLC) of High PErformance Radio Metropolitan Area Network (HIPERMAN) systems, which operate on frequencies 
between 2 GHz and 1 1 GHz. A separate ETSI document, TS 102 177 [3], specifies the PHY. 

With permission of IEEE® (on file as BRAN32_5d009), portions of the present document are excerpted from IEEE 
Standard 802.16-2002 and IEEE Standard 802.16a-2003. 
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Scope 



The present document supplements IEEE Standard P802. 16-2001 [1] as amended by IEEE Standard P802.16c [2], 
which defines the DLC and PHY of metropolitan area network systems operating on Ucensed frequencies between 
10 GHz and 66 GHz. The present document provides the supplemental DLC functions required for systems operating 
on licensed frequencies between 2 GHz and 1 1 GHz to support PMP and optionally Mesh network topologies. These 
supplemental DLC functions are defined to support the different physical environment that exists on frequencies 
between 2 GHz and 1 1 GHz compared to frequencies between 10 GHz and 66 GHz. 

The physical characteristics of frequencies between 2 GHz and 1 1 GHz, as well as the characteristics of the Broadband 
Wireless Access (BWA) market segments for which the present document is designed, result in an environment, where 
Line Of Sight (LOS) is not necessary, multipath may be severe and the physical medium may be lossy. 

The present document does not address the requirements and technical characteristics for conformance testing, nor the 
requirements for the appUcable 2 GHz to 1 1 GHz PHY Layer. Those are covered in separate documents. 
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Networks - Part 16: Air Interface for Fixed Broadband Wireless Access Systems - Detailed System 
Profiles for 10-66 GHz ". 

[3] ETSI TS 102 177: "Broadband Radio Access Networks (BRAN); HIPERMAN; Physical layer". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Adaptive Antenna System (AAS): system adaptively exploiting more than one antenna to improve the coverage and 
the system capacity 

NOTE: AAS-enabled in the context of a PMP BS denotes the implementation of AAS as defined. AAS-enabled 
in the context of a PMP SS denotes the ability to communicate with an AAS-enabled BS using the AAS 
specific mechanisms. Though a PMP SS may itself implement AAS as defined, this has no impact on the 
air interface and hence no specific differentiation is made. 

adaptive modulation: system's ability to communicate with another system using multiple burst profiles and a system's 
ability to subsequently communicate with multiple systems using different burst profiles 
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ARQ Block: distinct unit of data that is carried on an ARQ-enabled connection 



NOTE: Such a unit is assigned a sequence number, and is managed as a distinct entity by the ARQ state 
machines. 

bandwidth stealing: use, by a subscriber station operating on a grant per subscriber station basis, of a portion of the 
bandwidth allocated in response to a bandwidth request for a connection to send another bandwidth request rather than 
sending data 

NOTE: See also: grant per subscriber station. 

DC carrier: in an OFDM or OFDMA signal, the carrier whose frequency would be equal to the RF centre frequency of 
the station 

MeSH (MSH): network architecture, wherein systems are capable of forwarding traffic from and to multiple other 

systems 

RF centre frequency: centre of the frequency band in which a BS or SS is intended to transmit 

Rx/Tx Transition Gap (RTG): gap, used by TDD and H-FDD systems, between the uplink burst and the subsequent 
downlink burst 

NOTE: This gap allows time for the BS to switch from receive to transmit mode and SSs to switch from transmit 
to receive mode. During this gap, the BS and SS are not transmitting modulated data but simply allowing 
the BS transmitter carrier to ramp up, the Tx/Rx antenna switch to actuate, and the SS receiver sections to 
activate. 

SS Rx/Tx Gap (SSRTG): the minimum receive to transmit turnaround gap 

NOTE: SSRTG is measured from the time of the last sample of the received burst to the first sample of the 
transmitted burst, at the antenna port of the SS. 

SS Tx/Rx Gap (SSTTG): the minimum transmit to receive turnaround gap 

NOTE: SSTTG is measured from the time of the last sample of the transmitted burst to the first sample of the 
transmitted burst, at the antenna port of the SS. 

Tx/Rx Transition Gap (TTG): gap, used by TDD and H-FDD systems, between the downlink burst and the 
subsequent uplink burst 

NOTE: This gap allows time for the BS to switch from transmit to receive mode and SSs to switch from receive 
to transmit mode. During this gap, the BS and SS are not transmitting modulated data but simply allowing 
the BS transmitter carrier to ramp down, the Tx/Rx antenna switch to actuate, and the BS receiver section 
to activate. 

Turbo decoding: iterative decoding, using soft inputs and soft outputs 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

a Averaging parameter for CINR and RSSI computations 

RSSj^ jjjj^x Initial Ranging Max. Received Signal Strength at BS 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AAS Adaptive Antenna System 

ARQ Automatic Repeat reQuest 

BW Bandwidth 

CID Connection IDentifier 

CINR Carrier to noise and INterference Ratio 
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CSCF Centralized Scheduling ConFiguration 

CSCH Centralized SCHedule 

DCD DL Channel Descriptor 

DCE Downlink Channel Emission 

DIUC Downlink Interval Usage Code 

DSA-RSP Dynamic Service Addition-ReSPonse 

DSCH Distributed SCHedule 

DSC-REQ Dynamic Service Change-REQuest 

DSC-RSP Dynamic Service Change-ReSPonse 

FPC Fast Power Control 

FWA Fixed Wireless Access 

HCS Header Check Sequence 

H-FDD Half-duplex FDD 

IE Information Element 

LOS Line Of Sight 

MIMO Multiple In Multiple Out 

MS Mini-Slot 

MSH MeSH 

NCFG Network ConFiGuration 

NENT Network ENTry 

NLOS Non Line Of Sight 

OFDM Orthogonal Frequency Division Multiplexing 

OFDMA Orthogonal Frequency Division Multiple Access 

PKM Privacy Key Management 

PMP Point-to-MultiPoint 

REQ REQuest 

RNG RaNGing 

RSP Response 

RTG Receive/Transmit Transition Gap 

SNR Signal-to-Noise Ratio 

TTG Transmit/receive Transition Gap 

UCD UL Channel Descriptor 

UIUC UpUnk Interval Usage Code 



PDU formats 



4.1 MAC header type encodings 
4.1.1 Type encodings 

The Type field in the Generic MAC Header shall indicate the presence of subheaders and payload as shown in table 1 . 

Table 1 : Type encodings 



Type bit 


Value 


#0 (Isb) 


Grant Management Subheader 
1 = present, = absent 
Shall be on DL 


#1 


Packing Subheader 
1 = present, = absent 


#2 


Fragmentation Subheader 
1 = present, = absent 


#3 


ARQ Extended Packing/Fragmentation Subheader 
1 = extended, = not extended 


#4 


ARQ Feedback Payload 
1 = present, = absent 


#5 (msb) 


IVIesh Subheader 

1 = present, = absent 
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Four types of Subheaders may be present. The per-PDU subheaders (the Mesh subheader, the Fragmentation subheader 
and the Grant Management subheader) may be inserted in MAC PDUs immediately following the Generic MAC. If 
both the Fragmentation Subheader and Grant Management Subheader are indicated, the Grant Management Subheader 
shall come first. If the Mesh Subheader is indicated, it shall precede all other subheaders. 



4.1 .2 Header Check Sequence encoding 



The transmitter shall calculate the HCS value for the first five octets of the cell header, and insert the result into the 
HCS field (the last octet of the MAC header). It shall be the remainder of the division (Modulo 2) by the generator 
polynomial g(D) = D^+D^+D+l of the polynomial D^ multiplied by the content of the header excluding the HCS field. 



EXAMPLE: 



[HT EC Type] = 0x80, BR = OxAAAA, CID = OxOFOF; HCS should then be set to OxD5. 



4.2 



MAC subheaders 



4.2.1 



Mesh subheader 



The Mesh Subheader as shown in table 2 shall always immediately follow the generic MAC header when operating in 
Mesh mode, but shall not be used when operating in PMP mode. 

Table 2: Mesh subheader format 



Syntax 


Size 


Notes 


Mesh SubheaderO { 






Xmt Node Id 


16 bits 


Node Id of the originating mesh node. 


} 







4.2.2 ARQ feedback payload 



If the ARQ Feedback Payload bit in the MAC Header Type field (see table 1) is set, the ARQ Feedback Payload shall 
be transported. If packing is used, it shall be transported as the first packed payload. See clause 5.1.2. 



4.2.3 Fragmentation subheader 

The Fragmentation Subheader is shown in table 3. 



Table 3: Fragmentation subheader format 



Syntax 


Size 


Notes 


Fragmentation Subheader() { 






Fragmentation Control (FC) 


2 bits 


Indicates the fragmentation state of the payload: 

00 = no fragmentation 

01 = last fragment 

10 = first fragment 

1 1 = continuing (middle) fragment 


If (Type bit#3 (Extended Type) == 0) 




See table 1 . 


Fragmentation Sequence Number 
(FSN) 


3 bits 


Sequence number of the current SDU fragment. This 
field increments by one (modulo 8) for each fragment, 
including unfragmented SDUs. Applicable to 
connections where ARQ is not enabled. 


Else 






Block Sequence Number (SN) 


1 1 bits 


Sequence number of the first block in the current SDU 
or SDU fragment. This field increments by one 
(modulo 2 048) for each block. Applicable to 
connections where ARQ is enabled. 


Reserved 


3 bits 




1 
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4.2.4 Packing subheader 

When Packing is used, multiple SDUs may be packed into a single MAC PDU. When packing variable-length MAC 
SDUs, the MAC precedes each one with a Packing subheader as shown in table 4. 

Table 4: Packing subheader format 



Syntax 


Size 


Notes 


Packing SubheaderQ { 






Fragmentation Control 


2 bits 


Indicates the fragmentation state of the payload: 

00 = no fragmentation 

01 = last fragment 

10 = first fragment 

1 1 = continuing (middle) fragment 


If (Type bit#3 == 0) 




See table 1 


Fragmentation Sequence Number 


3 bits 


Sequence number of the current SDU fragment. This 
field increments by one (modulo 8) for each fragment, 
including unfragmented SDUs. Applicable to 
connections where ARQ is not enabled. 


Else 






Block Sequence Number 


1 1 bits 


Sequence number of the first block in the current SDU 
fragment. This field increments by one (modulo 2 048) 
for each block. Applicable to connections where ARQ 
is enabled. 


Length 


1 1 bits 


The length in bytes of the IVIAC SDU or SDU fragment, 
including the length of the Packing Subheader. 


} 







4.3 MAC management messages 

TLVs within MAC Management messages shall be ordered as follows. Parameters for optional features shall occur after 
those listed for support of mandatory features. Features that are defined optional, but are mandated by the implemented 
System Profile, if any, shall be ordered as optional. Both mandatory and optional TLVs shall subsequently be 
sequenced in order of increasing Type value. Parameters with defined default values should be omitted if the desired 
value coincides with the default one. 

When reporting parameters in MAC Management messages. Service Class Names should not be used. 

4.3.1 Supplemental MAC management messages 

As shown in table 5, supplemental MAC management messages are defined to facilitate ARQ, channel measurements 
and mesh functionality. 

Table 5: MAC management messages 



Type 


Message 


Connection 


Description 


33 


ARQ-Feedback 


Basic 




34 


ARQ-Discard 


Basic 




35 


ARQ-Reset 


Basic 




36 


REP-REQ 


Basic 




37 


REP-RSP 


Basic 




38 


FPC 


Broadcast 




39 


MSH-NCFG 


Broadcast 




40 


MSH-NENT 


Basic 




41 


MSH-DSCH 


Broadcast 




42 


MSH-CSCH 


Broadcast 




43 


MSH-CSCF 


Broadcast 




44 


AAS-FBCK-REQ 


Basic 




45 


AAS-FBCK-RSP 


Basic 




46-255 


Reserved 
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4.3.2 Type 1/3: DL/UL Channel Descriptor (DCD/UCD) message 

TLVs which may be included in the DCD message shall be limited to those listed in table 6. 

Table 6: DL Channel Descriptor TLVs 



Name 


Type 


Length 


Value 


Burst Profile 


1 


variable 


May appear more than once. The length is the number of bytes in 
the overall object, including embedded TLV items. See table 10. 


BSEIRP 


2 


2 


Signed in units of 1 dBm. 


TTG 


11 


1 


TTG (in PSs). See TS 102 177 [3], clause 14. 


RTG 


12 


1 


RTG (in PSs). See TS 102 177 [3], clause 14. 


£/RxP|Rn^g^ 


13 


1 


Maximum equivalent isotropic received power (see clause 8.1) in 
dB. Signed integer. 



Burst Profile encodings which may be included in the DCD message shall be limited those shown in table 7. 

Table 7: DL burst profile TLVs 



Name 


Type 


Length 


Value 


PEC Code Type 


2 


1 


= QPSK (RS+CC) 1/2 17 = 64QAM (CTC) 2/3 

1 = QPSK (RS+CC) 3/4 18 = 64QAM (CTC) 5/6 or 4/5 

2 = 1 6QAM ( RS+CC) 1/2 6-11,1 9-256 Reserved 

3 = 16QAM(RS+CC)3/4 

4 = 64QAM (RS+CC) 2/3 

5 = 64QAM (RS+CC) 3/4 

12 = QPSK (CTC) 1/2 

13 = QPSK (CTC) 2/3 

14 = QPSK (CTC) 3/4 

15 = 16QAM(CTC) 1/2 
16=16QAM(CTC)3/4 


DlUC Mandatory Exit 
Threshold 


13 


1 


- 63. 75 dB. 

C/(N+I) at or below which this DlUC can no longer be used and at 

which a change to a more robust DlUC is required, in 0,25 dB 

units. 


DlUC Mandatory Entry 
Threshold 


14 


1 


- 63. 75 dB. 

The minimum C/(N+I) required to start using this DlUC when 

changing from a more robust DlUC is required, in 0,25 dB units. 



TLVs which may be included in the UCD message shall be limited to those listed in table 8. 
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Table 8: UL Channel Descriptor TLVs 



Name 


Type 


Length 


Value 


Burst Profile 


1 


variable 


May appear more than once. The length is the number of bytes in 
the overall object, including embedded TLV items. See table 10. 


Frequency 


3 


4 


Uplink centre frequency (kHz). 


Contention-based 
Reservation Timeout 


10 


1 


Number of UL-MAPs to receive before contention- based 
reservation is attempted again for the same connection. 


Channel Width 


11 


2 


Uplink channel width, increments of 10 KHz. 


Sub-channelized initial 
ranging 


18 


1 


Indicates whether sub-channelized initial ranging is supported 

= Not supported 

1 = Supported. 


Sub-channelization 
focused contention code 


19 


1 


Number of contention codes (Cg^) that shall only be used to 

request a sub-channelized allocation. Default value 0. Allowed 
values 0-48. 


Sub-channelized REQ- 
Region-Full Parameters 


20 


1 


Bits 0...2: Number of sub-channels used by each transmit 
opportunity when REQ Region-Full is allocated in 
sub-channelization region, per the following enumeration; 
ObOOO: 1 Sub-channel. 
ObOOl: 2 Sub-channels. 
ObOlO: 4 Sub-channels. 
ObOII: 8 Sub-channels. 

Bits 3... 7: Number of OFDM symbols used by each transmit 
opportunity when REQ Region-Full is allocated in 
sub-channelization region. 



Burst Profile encodings which may be included in the UCD message shall be limited those shown in table 9. 

Table 9: UL burst profile TLVs 



Name 


Type 


Length 


Value 


FEC Code Type 


5 


1 


= QPSK (RS+CC) 1/2 17 = 64QAM (CTC) 2/3 

1 = QPSK (RS+CC) 3/4 18 = 64QAM (CTC) 5/6 or 4/5 
2= 16QAM (RS+CC) 1/2 6-11, 19-256 Reserved 

3 = 16QAM(RS+CC)3/4 

4 = 64QAM (RS+CC) 2/3 

5 = 64QAM (RS+CC) 3/4 

12 = QPSK (CTC) 1/2 

13 = QPSK (CTC) 2/3 

14 = QPSK (CTC) 3/4 
15=16QAM(CTC) 1/2 
16=16QAM(CTC)3/4 


Focused Contention 
Power Boost 


17 


1 


The power boost in dB of focused contention carriers. 
SeeTS 102 177 [3] for details. 



Table 10 defines the format of the Burst_Profile, which is used in both DCD and UCD messages. 

The Burst Profile is encoded with a Type of 1, an 8-bit length, and a 4-bit DIUC/UIUC which is associated with the 
Burst Profile and Thresholds. The DIUC/UIUC value is used in the DL-MAP respectively UL-MAP message to specify 
the Burst Profile to be used for a specific burst. 

Table 10: Burst profile format 



Syntax 


Size 


Notes 


DL/UL Burst Profile format { 






Type = 1 


8 bits 




Length 


8 bits 




Reserved 


4 bits 


Shall be set to 0. 


DIUC/UIUC 


4 bits 




TLV encoded information 


variable 




} 
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4.3.3 Type 2/3: DL-MAP / UL-MAP message 

The following formats shall be used in the DL-MAP and UL-MAP messages. 

4.3.3.1 DL-MAP PHY Synchronization Field 

The PHY Synchronization Field of the DL-MAP message shall have the format shown in table 11. 

Table 1 1 : PHY synchronization field 



Syntax 


Size 


Notes 


Synchronization field { 






Frame Number 


24 bits 




} 







Frame Number 

The modulo 2^^ frame number is increased by one every frame. 

4.3.3.2 DL-MAP IE format 

DL-MAP Information Elements shall have the format shown in table 12. 

Table 12: DL-MAP information element 



Syntax 


Size 


Notes 


DL-IVIAP information_element() { 






CID 


16 bits 




DlUC 


4 bits 




Preamble present 


1 bit 


= not present, 1 = present 
if DlUC == 15, shall be 


Start Time 


1 1 bits 




if (DlUC ==15) 






Extended DlUC dependent IE 


variable 


Report lEQcrAAS DL IE() or 
SIC IE() 


Padding nibble, if needed 


4 bits 


Completing to nearest byte 


} 







Connection Identifier (CID) 

Represents the assignment of the IE to a broadcast, multicast, or unicast address. 

Downlink Interval Usage Code (DlUC) 

A four -bit Downlink Interval Usage Code (DlUC) shall be used to define the burst type associated with that 
time interval. Burst Descriptor shall be included into DCD Message for each DlUC used in the DL-MAP 
except those associated with Gap, End of Map and Extended. The DlUC shall be one of the values defined in 
table 13. 

Preamble present 

If set, the indicated burst shall start with the short preamble. 

Start Time 

Indicates the start time, in units of symbol duration, relative to the beginning of the frame. The end of the last 
allocated burst is indicated by allocating a NULL burst (DlUC = 14) with zero duration. The time instants 
indicated by the Start Time values are the transmission times of the first symbol of the burst including 
preamble. 
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4.3.3.2.1 DlUC allocations 

Table 13 contains the DIUC values used in DL-MAP_IE(). 

Table 13: OFDM DIUC values 



DIUC 


Usage 





Reserved 


1-12 


Burst Profiles 


13 


Gap 


14 


End of Map 


15 


Extended DIUC 



4.3.3.2.2 



DL-MAP Report IE format 



The BS may use the DL-MAP Report IE to create a gap during which all SSs shall measure the background noise using 
the RSSI method. The IE shall be followed by the End of Map IE (DIUC = 14). 

Table 14: Channel measurement Information Element format 



Syntax 


Size 


Notes 


Report Information Element() { 






extended DIUC code 


4 bits 


Cliannel measurement = 0x0 


Length 


4 bits 


Length = 0x1 


Reserved 


8 bits 


Shall be set to 0x00 


} 







4.3.3.2.3 



DL-MAP AAS IE format 



Within a frame, the switch from non-AAS to AAS -enabled traffic is marked by using the extended DIUC =15 with the 
AAS_IE() shown in table 15 to indicate that the subsequent allocations, until the start of the first UL-MAP allocation 
using TDD, and until the end of the frame using FDD, shall be for AAS traffic. When used, the CID in the 
DL-MAP_IE() shall be set to the broadcast CID. Subsequent AAS PHY bursts shall all start with the short preamble. 

Table 15: AAS DL Information Element format 



Syntax 


Size 


Notes 


AAS DL Information element() { 






extended DIUC 


4 bits 


AAS = 0x2 


Length 


4 bits 


Length = 0x0 


} 







4.3.3.2.4 



DL-MAP STC IE format 



In the DL-MAP, an STC enabled BS may transmit DIUC = 15 with the STC_IE() shown in table 16 to indicate that the 
subsequent allocations shall be STC encoded. No preceding DL allocations shall be STC encoded and all subsequent 
DL allocations until the end of the frame shall be STC encoded. After this allocation, the BS shall transmit from both its 
antennas until the end of the frame. The first DL allocation following the STC_IE shall contain a preamble. The number 
of OFDM data symbols between two preambles and the number of OFDM data symbols between the last preamble and 
the end of the DL subframe must be even. 

Table 16: STC Information Element format 



Syntax 


Size 


Notes 


STC Information element() { 






extended DIUC code 


4 bits 


STC = 0x1 


Length 


4 bits 


Length = 0x0 


} 
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4.3.3.2.5 



DL-MAP DUMMY IE format 



A SS shall be able to decode the DL-MAP DUMMY IE for forward compatibility. A BS shall not transmit this IE 
(unless under test). A SS may skip decoding DL bursts scheduled after the Start Time of this IE within the current 
frame. 

Table 17: DL-MAP DUMMY Information Element format 



Syntax 


Size 


Notes 


DUMMY Information element() { 






extended DlUC 


4 bits 


0x2. ..OxF 


Length 


4 bits 


0..15 


Unspecified data 


LengthxS bits 




1 







4.3.3.3 



UL-MAP IE format 



The UL-MAP Information Element defines the physical parameters and the start time for UL PHY bursts. The format of 
UL-MAP elements is shown in table 18. 

When sub-channelization is active (see clause 4.3.3.3.4), UIUC 3 shall not be used. 

Table 18: OFDM UL-MAP Information Element format 



Syntax 


Size 


Notes 


UL-MAP information elementQ { 






CID 


16 bits 




UIUC 


4bits 




Reserved 


1 bit 




Start Time 


1 1 bits 




if (UIUC == 4) 






Focused contention IE() 


16 bits 




if (UIUC == 15) 






Extended UIUC dependent IE 


Variable 


AAS_UL_IE() or 
sub-channelization IE() 


else if (sub-channelization) { 




See clause 4.3.3.3.4. 


Duration 


1 1 bits 




Sub-channel Index 


5 bits 




Reserved 


2 bits 


Set to ObOO 


Midamble Present 


2 bits 


ObOO = Preamble only 

ObOl = Midambles after every 8 data 

symbols 

OblO = Midambles after every 16 data 

symbols 

Obi 1 = Midambles after every 32 data 

symbols 


1 






Padding nibble 


0/4 bits 


Shall be set to 0x0 


} 







Connection Identifier (CID) 

Represents the assignment of the IE to a unicast, multicast, or broadcast address. When specifically addressed 
to allocate a bandwidth grant, the CID may be either the Basic CID of the SS or a Traffic CID for one of the 
connections of the SS. 

Uplink Interval Usage Code (UIUC) 

Shall be used to define the type of uplink access and the burst type associated with that access. A Burst 
Descriptor shall be included into an UCD message for each Uplink Interval Usage Code that is to be used in 
the UL-MAP. The UIUC shall be one of the values defined in table 19. 
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Start Time 

Indicates the start time, in units of symbol duration, relative to the Allocation Start Time given in the UL-MAP 
message. For non-sub-channelized allocations, the duration of the burst is indicated as the difference between 
the start times of current and next map elements. The end of the last allocated burst is indicated by allocating a 
NULL burst (CID = and UIUC = 14). The time instant indicated by the Start Time value is the start of the 
transmission of the preamble. 

Duration 

Indicates the duration, in units of OFDM symbols, of the sub-channelized allocation. The duration is inclusive 
of the preamble and the midambles contained in the allocation. 

Sub-channel Index 
See table 1 . 

Midamble Present 

Indicates the preamble repetition interval in OFDM symbols. 

4.3.3.3.1 UIUC allocations 

Table 19 contains the UIUC values used in the UL-MAP_IE(). 

Table 19: UIUC values 



UIUC 


Usage 





Reserved 


1 


initial ranging 


2 


REQ Region Full 


3 


REQ Region Focused 


4 


Focused Contention IE 


5-12 


Burst Profiles 


13 


Gap 


14 


End of Map 


15 


Extended UIUC 



4.3.3.3.2 



UL-MAP focused contention IE format 



Table 20 defines the UL-MAP IE for allocation Bandwidth (BW) for a SS that requested bandwidth using Focused 
Contention Reservation Requests. This UL-MAP IE is identified by UIUC = 4 (see table 19). A SS responding to a 
bandwidth allocation using the Focused Contention IE shall start its burst with a short preamble (see clause 5.6) and use 
only the most robust mandatory burst profile in that burst. 

Table 20: Focused contention Information Element format 



Syntax 


Size 


Notes 


Focused Contention IE() { 






Transmit Opportunity Index 


6 bits 




Contention Channel Index 


6 bits 




Contention Code Index 


3 bits 




Reserved 


1 bit 


Shall be set to ObO 


} 







Transmit Opportunity Index 

Index number of the Transmit Opportunity that was used in the Bandwidth Request, which this message is 
responding to. Focused Contention Reservation Requests Transmit Opportunities are numbered from 63 to 0, 
starting from the beginning of the frame where the UL-MAP is transmitted. 

Contention Channel Index 

Index number of the Contention Channel that was used in the Bandwidth Request, which this message is 
responding to. 
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Contention Code Index 

Index number of the Contention Code that was used in the Bandwidth Request, which this message is 
responding to. 



4.3.3.3.3 



UL-MAP AAS IE format 



Within a frame, indication of AAS-enabled traffic is marked by using the extended UIUC = 15 with the AAS_IE() 
shown in table 21 to indicate that the subsequent allocations be for AAS traffic. When used, the CID in the 
UL-MAP_IE() shall be set to the broadcast CID. Subsequent AAS PHY bursts shall all start with the short preamble. 
Stations not supporting the AAS functionality may treat the AAS_IE as a start of gap. The AAS_IE() shall not be used 
in AAS private map messages. 

Table 21 : AAS UL IE format 



Syntax 


Size 


Notes 


AAS Information element() { 






extended UIUC code 


4 bits 


AAS = 0x02 


Length 


4 bits 


Length = 0x0 


} 







4.3.3.3.4 UL-MAP sub-channelization IE format 

Within a frame, the BS may allocate a portion of the UL allocations to sub-channelized traffic. 

Table 22: Sub-channelization IE format 



Syntax 


Size 


Notes 


Sub-channelization Information element() { 






extended UIUC code 


4 bits 


Sub-channelization = 0x03 


Length 


4 bits 


Length = 0x2 


Length of Allocations 


16 bits 




} 







Length of allocations 

The number of bytes, following the sub-channelization_IE, that are used to define sub-channelized allocations. 
A SS not capable of using sub-channelization may skip interpreting this number of bytes in the UL-MAP. 



4.3.3.3.5 



UL-MAP DUMMY IE format 



An SS shall be able to decode the UL-MAP DUMMY IE for forward compatibility. A BS shall not transmit this IE 
(unless under test). 

Table 23: UL-MAP DUMMY Information Element format 



Syntax 


Size 


Notes 


DUIVIMY Information element() { 






extended UIUC 


4 bits 


0x4.. .OxF 


Length 


4 bits 


0...15 


Unspecified data 


LengthxS bits 




1 







4.3.4 Type 4/5: RaNGing REQuest/ReSPonse (RNG-REQ/RSP) message 

In addition to the TLVs listed in IEEE P802.16-2001 [1], the following TLVs are defined. 
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4.3.4.1 



AAS Support 



To indicate whether it can receive broadcast transmissions, an AAS-enabled SS may include the following TLV in 
RNG-REQ messages: 

AAS Broadcast Capabihty 

Table 24: Supplemental RNG-REQ TLVs 



Name 


Type 


Length 


Value 


AAS broadcast 
capability 


4 


1 


= SS can receive broadcast messages. 

1 = SS cannot receive broadcast messages. 



To indicate whether an SS, which set the AAS Broadcast Capability, may issue contention-based BW requests, an 
AAS-enabled BS may use the following TLV in RNG-RSP messages: 
AAS Broadcast Permission 

The following RNG-RSP TLVs may be sent by the BS to indicate the reception of an undecodable initial ranging 
(RNG-REQ) attempt or to indicate the reception of a sub-channelized initial ranging attempt. 
Frame Number: 

Initial Ranging Opportunity Number 

Table 25: Supplemental RNG-RSP TLVs 



Name 


Type 


Length 


Value 


Timing Adjust 


1 


4 


Tx timing offset adjustment (signed 32-bit). The time by 

which to advance SS transmission so that frames arrive at 

the expected time instance at the BS. Units are PHY 

specific. 

See TS 1 02 1 77 [3], clause 1 4 for unit definition. 


AAS broadcast 
permission 


16 


1 


= SS may issue in contention-based BW requests. 


AAS broadcast 
capability 


17 


1 


= SS can receive broadcast messages. 

1 = SS cannot receive broadcast messages. 


Frame Number 


18 


3 


Frame number in which the undecodable initial ranging or 
sub-channelized initial ranging attempt was detected by 
the BS. Usage is mutually exclusive with SS IVIAC 
Address. The opportunity within the frame is assumed to 
be 1 (the first) if the Initial Ranging Opportunity Number 
field is not supplied. 


Initial Ranging 
Opportunity Number 


19 


1 


Initial Ranging opportunity (1-255) in which the 
undecodable initial ranging or sub-channelized initial 
ranging attempt was detected by the BS. Usage is 
mutually exclusive with SS IVIAC Address. 



4.3.4.2 Power management support 

Table 26: TLVs for power management 



Name 


Type 
(1 byte) 


Length 


Value 
(Variable Length) 


Power level Adjust 


2 


1 


Tx Power offset adjustment (signed 8-bit, 0,25 dB 

units). 

Specifies the relative change in transmission power 

level that 

the SS is to make in order that transmissions arrive at 

the BS at 

the desired power. 

When sub-channelization is employed, The subscriber 
shall interpret the power offset adjustment as a required 
change to the transmitted power density. 
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4.3.5 Type 6: REGistration-REQuest (REG-REQ) message 

In PMP mode during Registration, the SS shall generate REG-REQ messages including the following parameter in 
addition to those specified in IEEE P802. 16-2001 [1]: 

MAC Version 

Maximum transmit power 

Amplifier backoffs 

Current transmitted power. 

The transmitted power parameters are defined in table 27. 

Table 27: Transmitted power parameters 



Name 


Type 
(1 byte) 


Length 


Value 
(Variable Length) 


Scope 


Maximum Tx Power 


5.23 


1 


Achievable transmit power (peak) signed, 
0,5 dB increments. 




Amplifier Bacl<offs 


5.24 


3 


Byte 0: QPSK 

Byte1:16QAM 

Byte 2: 64QAIVI (report as 0x0 if not 

supported). Backoff values in 0,25 dB 

increments. 




Current Tx power 


5.25 


1 


Current transmit power (peak) signed. 
0,5 dB increments. 





In Mesh mode during Registration, the Candidate Node shall generate REG-REQ messages including the following 
parameters: 

SS MAC Address 

MAC Version 

The MAC version implemented in the Candidate Node 

HMAC Tuple 

Message digest calculated using HMAC_KEY_U 

Both in PMP and Mesh mode, the REG-REQ may in addition contain the following parameters: 
IP Version 

SS Capabilities Encodings 
Vendor ID Encoding 

4.3.6 Type 7: REGistration-ReSPonse (REG-RSP) message 

In Mesh mode during Registration, the Registration Node shall generate REG-RSP messages including the following 
parameters: 

Node ID 

MAC Version 

MAC Version used in the network 

HMAC Tuple 

Message digest calculated using HMAC_KEY_D 

In Mesh mode, the REG-RSP may in addition contain the following parameters: 
IP Version 
SS Capabilities Encodings 

Capabilities returned in the REG-RSP shall not be set to require greater capability of the Node than is 
reported in the REG-REQ. 

Vendor Specific Extensions 
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4.3.7 Type 9/10: Privacy Key Management (PKM-REQ/RSP) messages 

In Mesh mode, the Authorization reply attributes and the Key request attributes listed in tables 28 and 29 shall be used. 
The HMAC-Digest's authentication key is derived from the Authorization key or the Operator Shared Secret. 

Table 28: Authorization Reply attributes 



Attribute 


Contents 


Operator Shared Secret 


Key l<nown to all nodes 


Key-Sequence-Number 


Operator Shared Secret 's sequence number 


Key-Lifetime 


Operator Shared Secret 's active lifetime 



Table 29: Key Request attributes 



Attribute 


Contents 


SS Certificate 


X.509 Certificate of the node 


SAID 


SA Identifier 


HIVIAC-Digest 


HMAC using HMAC KEY S 



4.3.8 Type 12: Dynamic Service Addition-ReSPonse (DSA-RSP) 

No TLVs besides Error Encodings and HMAC Tuples shall be reported back in DSA-RSP. 

4.3.9 Type 13: Dynamic Service Addition-ACKnowledgement (DSA-ACK) 

No TLVs besides HMAC Tuples shall be reported back in DSA-ACK messages. 

4.3.1 Type 1 4: Dynamic Service CInange-REQuest (DSC-REQ) 

DSC-REQ messages shall not contain Request/Transmission Policy, Fixed vs. Variable Length SDU Indicator, SDU 
Size, ATM Switching, or Convergence Sublayer Specification TLVs. 

4.3.1 1 Type 1 5: Dynamic Service CInange-ReSPonse (DSC-RSP) 

No TLVs besides Error Encodings and HMAC Tuples shall be reported back in DSC-RSP. 

4.3.12 Type 26/27: SS Basic Capability-REQuest/ReSPonse 
(SBC-REQ/RSP) 

The following Physical Parameter encodings shall be available for use with SBC-REQ and SBC-RSP. The Physical 
Parameters listed in IEEE P802. 16-2001 [1] shall not be used. 



4.3.12.1 



OFDM demodulator 



This field indicates the different demodulator options supported by a SS for DL reception. A bit value of indicates 'not 
supported' while 1 indicates 'supported.' 



Type 


Length 


Value 


Scope 


5.12.28 


1 


bit#0 64-QAM 

bit#1 Reserved. Set to 

bit#2 CTC 

bit#3 STC 

bit#4 AAS 

bit#5-7 Reserved. Set to 


SBC-REQ 
SBC-RSP 
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4.3.12.2 



OFDM modulator 



This field indicates the different modulator options supported by a SS for UL transmission. A bit value of indicates 
'not supported' while 1 indicates 'supported.' 



Type 


Length 


Value 


Scope 


5.12.29 


1 


bit#0 64-QAM 

bit#1 Reserved. Set to 

bit#2 CTC 

bit#3 Sub-channelization 

bit#4 Focused contention BW request 

bit#5-7 Reserved. Set to 


SBC-REQ 
SBC-RSP 



4.3.1 2.3 Subscriber transition gaps 

This field indicates the transition speed SSTTG and SSRTG for TDD and H-FDD SSs. 



Type 


Length 


Value 


Scope 


5.12.30 


2 


Bit #0-7: SSTTG (|js) 
Bit #8-15: SSRTG (MS) 
Allowed values: TDD: 0...50 |js; H-FDD: 0...100 |js 


SBC-REQ 
SBC-RSP 



4.3.12.4 Bandwidth allocation support 

This field indicates the different BW allocation options supported by a SS. A bit value of indicates 'not supported' 
while 1 indicates 'supported.' 



Type 


Length 


Value 


Scope 


5.15 


1 


bit #0: Reserved. Set to 








bit#1 = 0: Half-Duplex 


SBC-REQ 






bit#1 = 1: Full-Duplex 


SBC-RSP 






bit #2-7: reserved; shall be set to zero 





4.3.13 Type 33: ARQ Feedback message 

A system supporting ARQ shall be able to receive and process the ARQ Feedback message. 

The ARQ Feedback message, as shown in table 30, can be used to signal any combination of different ARQ ACKs 
(cumulative, selective, selective with cumulative). The message shall be sent on the appropriate basic management 
connection. 

Table 30: ARQ Feedback message format 



Syntax 


Size 


Notes 


ARQ Feedback Message Format() { 






IVIanagement Message Type = 33 


8 bits 




ARQ Feedback Payload 


variable 


See table 60. 


} 







ARQ Feedback information shall be either sent using this ARQ Feedback message or by packing the 
ARQ_Feedback_Payload as described in clause 5.1.2. 

4.3.14 Type 34: ARQ_Discard message 

This message is applicable to ARQ-enabled connections only. 

The transmitter sends this message when it wants to skip a certain number of ARQ blocks. The ARQ Discard message 
shown in table 3 1 shall be sent as a MAC management message on the basic management connection of the appropriate 
direction. 
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Table 31 : ARQ Discard message format 



Syntax 


Size 


Notes 


ARQ Discard Message Format() { 






Management Message Type = 34 


8 bits 




Connection ID 


16 bits 


Applicable CID. 


Reserved 


5 bits 




Block Sequence Number 


1 1 bits 


Sequence number of the last block in the transmission 
window to be discarded. 


} 







4.3.15 Type 35: ARQ_Reset message 

This message is applicable to ARQ-enabled connections only. 

The transmitter or the receiver may send this message. The message is used in a three-part dialog to reset the parent 
connection's ARQ transmitter and receiver state machines. The ARQ Reset message, as shown in table 32, shall be sent 
as a MAC management message on the basic management connection of the appropriate direction. 

Table 32: ARQ_Reset message format 



Syntax 


Size 


Notes 


ARQ Reset Message Format() { 






Management Message Type = 36 


8 bits 




Connection ID 


16 bits 


Applicable CID 


Type 


2 bits 


00 = Original Message from Initiator 

01 = Acknowledgement from Responder 

10 = Confirmation from Initiator 

1 1 = Reserved 


Reserved 


6 bits 




} 







4.3.1 6 Type 36/37: Report-Request (REP-REQ/RSP) message 

The Report Request message, shown in table 33, shall be used by the BS to request RSSI and CINR channel 
measurement reports. 

Table 33: REP-REQ message format 



Syntax 


Size 


Notes 


Report Request Message Format() { 






Management Message Type = 36 


8 bits 




Report Request TLV 


variable 




} 







The Report Request TLV shall have the format shown in table 34. 

Table 34: Report Request TLV 



Name 


Type 


Lengtii 


Value 


Report Request 


1 


Variable 





The Report Request shall consist of the parameters in table 35. 
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Table 35: Report Request parameters 



Name 


Type 


Length 


Value 


Report Type 


1.1 


1 


Bit #0 Reserved, shall be set to 

bit #1 1 = Include CINR report 

bit #2 1 = Include RSSI report 

bit #3-6 Qgyg in multiples of 1/32 (range [1/32, 16/32]) 

See TS 102 177 [3], clause 10.2 

bit #7 1 = Report background noise 



When bit#7 is set, bit#l shall be and bit#2 shall be 1. The response shall contain the RSSI as measured during the 
period indicated by the last DL-MAP Report IE. 

The Report Response message, shown in table 36 shall be used by the SS to respond with the channel measurements 
requested in the last received Report Request. 

Table 36: REP-RSP message format 



Syntax 


Size 


Notes 


Report Response Message Format() { 






Management Message Type = 37 


8 bits 




Current Tx Power 


8 bits 


Current transmit power (peak) in 0,5 dB increments 


Report Response TLV 


variable 


Compound TLV that shall contain the measurement 
Report in accordance with the Report Request 


} 







The Report Response TLV shall have the format shown in table 37. 

Table 37: Report Response TLV 



Name 


Type 


Length 


Value 


Report Response 


1 


Variable 





The Report Response shall consist of the parameters in table 38. 

Table 38: Report Response parameters 



Name 


Type 


Length 


Value 


CINR Report 


1.3 


2 


Insert if REP-REQ bit#1 = 1. 

1 byte CINR mean 

1 byte CINR standard deviation 


RSSI Report 


1.4 


2 


Insert if REP-REQ bit#2 = 1. 

1 byte RSSI mean 

1 byte RSSI standard deviation 



£75/ 



25 



ETSI TS 102 178 VI. 1.1 (2003-11) 



4.3.17 Type 38: Fast Power Control (FPC) message 

Power control shall be provisioned by the use of periodic ranging. In addition, the BS may adjust the power levels of 
multiple subscribers simultaneously with the Fast Power Control (FPC) message. SSs shall apply the indicated change 
within the "SS DL management message processing time". PFC shall be sent on the broadcast CID. 

Table 39: Fast Power Control message format 



Syntax 


Size 


Notes 


Fast Power Control message format () { 






Management message type = 38 


8 bits 




Number of stations 


8 bits 




for (i = 0;i<Number of stations;i++) { 






Basic CID 


16 bits 




Power Adjust 


8 bits 




} 






} 







Number of stations 

Number of CID and Power Adjust tuples contained in this message. 

Basic CID 

Basic connection identifier associated with the SS. 

Power Adjust 

Signed integer, which expresses the change in power level (in multiples of 0,25 dB) that the SS shall apply to 
its current transmission power. 

4.3.18 Type 39: MeSH Network ConPiGuration (MSH-NCPG) message 

MeSH Network ConFiGuration (MSH-NCFG) messages provide a basic level of communication between nodes in 
different nearby networks whether from the same or different equipment vendors or wireless operators. All the nodes 
(BS and SS) in the mesh network shall transmit MSH-NCFGs as described in clause 6.5.2. 

The MSH-NCFG packets shall be used to convey information about network status and configuration such as: 

Synchronization across multiple mesh networks; 
Communication of channels in use across multiple networks; and 
Support of network entry for new or mobile nodes. 

All the nodes shall generate MSH-NCFGs in the format shown in table 40. 
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Table 40: MSH-NCFG message format 



Syntax 


Size 


Notes 


Report Response Message Format() { 






IVIanagement IVIessage Type = 39 


8 bits 




NumNbrEntries 


5 bits 




NumBSEntries 


2 bits 


Number of mesh BS neighbours to be reported on 


Embedded Pacl<et Flag 


1 bit 


1 = present, = not present 


Xmt Power 


4 bits 


In 2 dBm steps, starting from 0x0 = 8 dBm 


Xmt Antenna 


3 bits 


Antenna used for transmission of this message 


NetEntry MAC Address Flag 


1 bit 


1 = present, = not present 


Network Base Channel Logical Number 


4 bits 




Reserved 


4 bits 




NetConfig Counter 


4 bits 


Incremented by 1 for every transmitted MSH-NCFG 


TimeStamp 

Frame_Number 

Network Ctrl Slot Number in frame 

Number of hops to master sync, node 


12 bits 
4 bits 
8 bits 




NetConfig Schedule Info 
Next Xmt Mx 
Xmt Holdoff Exponent 


3 bits 
5 bits 




If (NetEntry_MAC_Address_Flag) 
NetEntry MAC Address 


48 bits 




for (i = 0; i<NumBSEntries;++i) { 






BS Node ID 


1 6 bits 


Node ID of the mesh BS reported on 


Number of hops to BS 


3 bits 


Number of hops to this mesh BS 


Xmt energy/bit to BS 


5 bits 




} 






for (i = 0; i<NumNbrEntries;++i) { 






NbrNodelD 


16 bits 


Node ID of the neighbour node reported on 


MSH-NCFG Nbr Physical IE() 


16 bits 


See table 41 


if (Logical Link Info Present) 
MSH-NCFG Nbr Logical lEQ 


16 bits 


Indicated in preceding MSH-Nbr Physical IE() 
See table 42 


} 






If (Embedded Packet Flag) 

MSH-NCFG embedded dataQ 


variable 




1 







NumNbrEntries 

Number of neighbours reported on in the message. The number of neighbours reported on may be a fraction of 
the whole set of neighbours known to this node. A node can report on subsequent subsets of neighbours in its 
subsequent MSH-NCFG transmissions. 
The following procedure is used to select the list neighbours of which only the Physical IE is reported: 

i) All neighbour entries with the 'Reported Flag' set to TRUE are excluded as defined below 

ii) The remaining neighbour entries are ordered by the Next Xmt Time and those with the Next Xmt Time 
the furthest in the future are reported in this MSH-NCFG packet. (In general, learning of nodes with Next 
Xmt Times furthest into the future is more valuable than learning of nodes with Next Xmt Times 
approaching soon, since the neighbours will have more time to use this ineligibility information before it 
is stale.) 

The 'Reported Flag' for all neighbours in either of the above neighbour lists is set to TRUE upon transmission 
of this MSH-NCFG packet. It is set to FALSE as described in clause 6.5.1. 

Network Base Channel Logical Number 

The logical number of the base channel being used in this node's network, which is the logical number of the 
physical channel which shall be used to broadcast schedule control information. The possible physical channel 
numbers is mapped to logical channels in the Network Descriptor (see clause 4.3.18.3.1). 

Netconfig counter 

Counter of MSH-NCFG packets transmitted by this node. Used by neighbours to detect missed transmissions. 
Incremented by 1 for every MSH-NCFG transmission by this node. 
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Frame number 

A modulo 2^2 number, which shall be increased by one for every frame. 

Network Control Slot Number in frame 
See TS 102 177 [3] for details. 

Number of hops to master sync, node 

This counter is used to determine superiority between nodes when synchronizing the network. Nodes can be 
assigned as master time keepers, which are synchronized externally (for example using GPS). Nodes shall 
synchronize to the node with the lowest number of hops to master sync, node, or if counts are the same, to the 
node with the lower Node ID. 

Netconfig Schedule Info 

Xmt Holdoff Exponent 

The Xmt Holdoff Time is the number of MSH-NCFG transmit opportunities after Next Xmt Time (there are 
MSH-CTRL-LEN -1 opportunities per network control subframe, that this node is not eligible not transmit 
MSH-NCFG packets. 

Xmt Holdoff Time = l^^"^' ""''^"^^ Exponent +4) ^ j^ 

Next Xmt Mx 

Next Xmt Time is the next MSH-NCFG eligibility interval for this neighbour and computed as the range: 

2Xmt Holdoff Exponent ^ ^^^^ ^mt Mx < Next Xmt Time < 2^'"' "°''^°*'*' ^''P^'^"' x (Next Xmt Mx + 1). (2) 

For example, if Next Xmt Mx = 3 and Xmt Holdoff Exponent = 4, then the node shall be considered eligible 
for its next MSH-NCFG transmission between 49 and 64 (due to the granularity) transmission opportunities 
away and ineligible before that time. 

If the Next Xmt Mx field is set to OxlF (all ones), then the neighbour should be considered to be eligible to 
transmit from the time indicated by this value and every MSH-NCFG opportunity thereafter (i.e. treat Xmt 
HoldoffTime = 0). 

NetEntry MAC Address 

Indicates presence or sponsorship of new node. See MSH-NENT message in clause 4.3.19 and network entry 
in clause 6.6. 

Xmt energy/bit factor 

Indication of energy /bit needed to reach mesh BS through this node. Xmt energy/bit is computed as: 

Ei = min [Pj^ I Ri^ j+eA mWjUs (3) 

where: A' is the set of neighbours reporting this mesh BS: 

Pjj^ is the transmission power in mW from node ; to nodey 

Ri^ j is the datarate in Mbps from node ; to node j. 

E j is the Xmt energy/bit reported by neighbour y. 

The reported Xmt energy/bit factor is computed as: 

Xmtenergy/bitfactor = X-^--gy^)/(,^,,„,,^^,„,,,p_,,^ (4) 

where XmtEnergyUrritExponent is a 4-bit field reported in the most recent Network Descriptor. 
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4.3.18.1 Nbr Physical Information Element 



Table 41 : MSH-NCFG_Nbr_Physical_lnformation_Element 



Syntax 


Size 


Notes 


MSH-NCFG Nbr Ptiysical IE() { 






Logical Linl< Info Present 


1 bit 


Indicates whether MSH-NCFG Nbr Logical IE follows 


Logical Link requested 


1 bit 


1 = Yes, = No 


Logical Link Accepted 


1 bit 


1 = Yes, = No 


Hops to Nbr 


1 bit 


= 1 hop (direct neighbour), 1 = 2 hops 


Propagation delay 


4 bits 


Estimated propagation delay in |js 


Nbr NetConfig Schedule Info 
Nbr Next Xmt Mx 
Nbr Xmt Holdoff Exponent 


5 bits 
3 bits 




} 







4.3.18.2 Nbr Logical Information Element 



Table 42: MSH-NCFG_Nbr_Logical_lnformation_Element 



Syntax 


Size 


Notes 


MSH-NCFG Nbr Logical IE() { 






Rev Link Quality 


3 bits 




Nbr Burst Profile 


4 bits 




Excess Traffic Demand 


1 bit 


1 = Yes, = No 


Nbr Xmt Power 


4 bits 


(see table 40) 


Nbr Xmt Antenna 


3 bits 


(see table 40) 


Short Preamble Flag 


1 bit 


= don't use, 1 = use requested/confirmed 


} 







Rev Link Quality 

Measure of the receive link reliability, indicating the reliability of MSH-NCFG size packets using the 
indicated burst profile. The estimated reliability is indicated as: 



reliability = 100x 1-10' 



-(Rev Link Quality+1 )/4'^ 



% 



(5) 



Nbr burst profile 

Indicated the burst profile the indicated node should use when sending data bursts to the reporting node. 

Excess traffic demand 

May be used to indicate to the neighbour that the current schedule is insufficient to transfer pending traffic. 

Short Preamble flag 

A node may optionally set this bit to notify the neighbour to use the short preamble for transmissions in the 
data portion of the frame. Capability to transmit the short preamble is mandatory. Capability to receive it is 
optional. 
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4.3.18.3 Embedded data 

The Embedded Data shall consist of the form shown in table 43. 



Table 43: MSH-NCFG Embedded Data 



Syntax 


Size 


Notes 


MSH-NCFG Embedded Data() { 






Extended embedded_data 


1 bit 


Indicates whether this embedded IE is followed by 
another one. 
= No, 1 = Yes 


Reserved 


3 bits 




Embedded_Data_IE_Type 


4 bits 


0x0 = Reserved 

0x1 = Network Descriptor 

0x2 = Network Entry Open 

0x3 = Network Entry Reject 

0x4 = Network Entry Ack (Length shall be set to 0) 

0x5 = Neighbour Link Establishment Protocol 


Length 


8 bits 


Length of the MSH-NCFG_Embedded_Data_IE in 
bytes, exclusive this header 


MSH-NCFG Embedded data IE() 


variable 


Embedded Data IE Type dependent 


1 







4.3.18.3.1 Network Descriptor Embedded Data Information Element 

The Network Descriptor Embedded_data_IE shall contain the shown in table 44. 

Table 44: Network Descriptor Information Element 



Syntax 


Size 


Notes 


MSH-NCFG Embedded Data IE() { 






Frame Length Code 


4 bits 


4 Isb of Frame Duration Code. See TS 102 177 [3] 


MSH-CTRL-LEN 


4 bits 


Control subframe length 


MSH-DSCH-NUM 


4 bits 


Number of DSCH opportunities in schedule control 
subframe 


MSH-CSCH-DATA-FRACTION 


4 bits 




Scheduling Frames 


4 bits 


Defines how many frames have a schedule control 
subframe between two frames with network control 
subframes in multiples of 4 frames 

= frames; 

1 = 4 frames etc. 


Num_Burst_Profiles 


4 bits 




Operator ID 


16 bits 




XmtEnergyUnitsExponent 


4 bits 




Num Channels 


4 bits 


Number of logical channels 


MInCSForwardingDelay 


7 bits 


Number of OFDM symbols delay inserted between 
receiving and forwarding control packets 


ExtendedNeighborhoodlype 


1 bit 


= 2-hop neighbourhood 

1 = 3-hop neighbourhood 


If (Num Channels) 

MSH-NCFG NetDesc Channel IE() 


variable 




for (i = 0;i < BurstProfileCount;i++) { 






FEC Code Type 


8 bits 


See table 8 


Mandatory Exit Threshold 


8 bits 


Mandatory Entry Threshold 


8 bits 


1 






} 







MSH-CSCH-DATA-FRACTION 

Maximum percentage (value x 6.67) of minislots in the data-subframe allocated to centralized scheduling. The 
number of minislots is rounded to the nearest whole number of minislots and allocated starting from the 
beginning of the data subframe. The remainder of the data subframe, as well as any minislots not occupied by 
the current centralized schedule, may be used for distributed scheduling. 
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ExtendedNeighborhoodType 

If value 0, then only nodes with Hops to Neighbour = are reported, if value 1, then also nodes with Hops to 
Neighbour = 1 are reported. 

MinCSForwardingDelay 

The minimum delay in OFDM symbols that shall be inserted between the end of reception and the start of 
transmission of a Centralized Scheduling message (i.e. MSH-CSCH and MSH-CSCF) by any node. 

Table 45: MSH-NCFG NetDesc Channel Information Element 



Syntax 


Size 


Notes 


MSH-NCFG NetDesc Channel IE() { 






for (i = 0;i< Channels; ++i) { 




PHY dependent. Index 'i' corresponds to logical 
channel 


Physical channel centre frequency 


24 bits 


Positive integer in kHz 


Physical channel width 


8 bits 


Positive integer in 100 kHz 


} 






Channel Re-use 


3 bits 


Minimum number of hops of separation between links, 
before a channel can be re-used by the centralized 
scheduling algorithm. Range is 1 hop to 7 hops, for 
no re-use 


Reserved 


5 bits 




} 







4.3.18.3.2 



Network Entry Open Embedded Data Information Element 



The Network Entry Open, which is used to respond to MSH-NENT request messages, shall contain the form as shown 
in table 46. 

Table 46: Network Entry Open Information Element 



Syntax 


Size 


Notes 


MSH-NCFG Embedded Data IE() { 






Minislot Start 


8 bits 


Schedule start for upper layer network entry 


Minislot Range 


8 bits 


Schedule range for upper layer network entry 


Frame number 


12 bits 


Frame number this schedule becomes valid 


Channel 


4 bits 


Logical channel for new node to Xmt in above Minislot 
Range 


Schedule validity 


12 bits 


Validity of Schedule in frames 


Channel 


4 bits 


Logical Rev channel for new node 


Estimated Propagation Delay 


4 bits 


In jjs 


Reserved 


4 bits 




1 







4.3.18.3.3 



Network Entry Reject Embedded Data Information Element 



The Network Entry Reject, which is used to reject MSH-NENT request messages, shall contain the form as shown in 
table 47. 

Table 47: Network Entry Reject Information Element 



Syntax 


Size 


Notes 


MSH-NCFG Embedded Data IE() { 






Rejection Code 


8 bits 


0x0: Operator Authentication Value Invalid 
0x1 : Excess Propagation delay 
0x2: Select new sponsor 


Rejection Reason 


160 bits 


ASCII string 


} 
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4.3.18.3.4 



Neighbour Link Establishment Embedded Data Information Element 



The Neighbour Link Establishment, which is used to establish links between nodes as described in clause 6.2, shall 
contain the form as shown in table 48. 

Table 48: Link Establishment Information Element 



Syntax 


Size 


Notes 


MSH-NCFG Embedded Data IE() { 






Action Code 


2 bits 


0x0 = Challenge 

0x1 = Challenge Response 

0x2 = Accept 

0x3 = Reject 


Reserved 


6 bits 




If (Action Code == 0x0 or 0x1) 
Nbr Authentication Value 


32 bits 




If (Action Code == 0x1 or 0x2) 
Link ID 


8 bits 


Transmitting node's Link ID for this link 


} 







Nbr Authentication Value 

Nbr Authentication Value = HMACJAuthorization Key I Frame Number I Node ID self I Node ID other} (6) 
where the Authorization Key is a secret key (obtained from Operator) 

4.3.19 Type 40: MeSH-Network ENTry (MSH-NENT) message 

MeSH Network ENTry (MSH-NENT) messages provide the means for a new node to gain synchronization and initial 
network entry into a mesh network. When a MSH-NENT message, shown in table 49, is sent, the mesh Subheader is set 
to 0x0000 until the node has been assigned a node ID. In the Mesh CID, The Network ID is set the sponsor's network 
code or to 0x0000 if not known and the Link ID is set to OxFF (Broadcast). 

Table 49: MSH-NENT message format 



Syntax 


Size 


Notes 


MSH-NENT Message FormatO { 






MAC Management Message Type = 40 


8 bits 




MSH-NENT_Type 


3 bits 


0x0 = Reserved 
0x1 = NetEntryAck 
0x2 = NetEntryRequest 
0x3 = NetEntryClose 


If (MSH-NENT Type ==0x1) 

MSH-NENT_Type being Ack-ed 

else 

Xmt counter for this MSH-NENT Type 


3 bits 
3 bits 




Reserved 


2 bits 




Sponsor Node ID 


1 6 bits 


ID of the node sought to assist the requesting node in 
entering the network 


Xmt Power 


4 bits 


See table 40 


Xmt Antenna 


3 bits 


See table 40 


Reserved 


1 bit 




If (MSH-NENT Type == 0x2) 






MAC Address 


48 bits 


MAC Address of the new node sending the request. 


OpConflnfo 


64 bits 


Operator Configuration Information (obtained from 
Operator) 


Operator Authentication Value 


32 bits 




Node Serial Number 


32 bits 




} 






} 
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Operator Authentication Value 

Operator Authentication Value = HMACJMAC Address I Node Serial Number I Authorization Key} (7) 
where the Authorization Key is a secret key (obtained from Operator) 

4.3.20 Type 41 : MeSH-Distributed SCHeduling (MSH-DSCH) message 

MeSH Distributed SCHeduling (MSH-DSCH) messages shall be transmitted in mesh mode when using distributed 
scheduling. In coordinated distributed scheduling, all the nodes shall transmit a MSH-DSCH, shown in table 50 at a 
regular interval to inform all the neighbours of the schedule of the transmitting station. This transmission time is 
determined by the same algorithm used for MSH-NCFG messages. In both coordinated and uncoordinated scheduling, 
MSH-DSCH messages shall be used to convey resource requests and grants to the neighbours. Further the MSH-DSCH 
messages shall be used to convey information about free resources that the neighbours can issue grants in. This message 
shall not be fragmented. 

Table 50: MSH-DSCH message format 



Syntax 


Size 


Notes 


MSH-DSCH Message Format() { 






MAC Management Message Type = 41 


8 bits 




Coordination Flag 


1 bit 


= Coordinated 

1 = Uncoordinated 


Grant/Request Flag 


1 bit 


= Request message 

1 = Grant message (also used as Grant confirmation) 


MSH-DSCH Sequence Counter 


6 bits 




Num Requests 


4 bits 


Number of Request lEs in tfie message 


Num_Availabilities 


4 bits 


Number of Availability lEs in the message. The 
Availability lEs are used to indicate free minislot 
ranges that neighbours could issue Grants in 


Num Grants 


6 bits 


Number of Grant lEs in this message 


Reserved 


2 bits 




if (Coordination Flag == 0x0) 
MSH-DSCH Scheduling IE() 


variable 




for (i = 0;i< Num Requests; ++i) 
MSH-DSCH Request IE() 


16 bits 




for (i = 0;i< Num Availabilities; ++i) 
MSH-DSCH Availability IE() 


32 bits 




for (i = 0;i< Num Grants; ++!) 
MSH-DSCH Grant IE() 


40 bits 




} 







Co-ordination Flag 

Coordinated MSH-DSCH transmissions take place in the control subframe. Uncoordinated MSH-DSCH 
transmissions take place in the data subframe. Both the cases require a threeway handshake (Request, Grant 
and Grant confirmation) to establish a valid schedule. Uncoordinated scheduling may only take place in 
miruslots which cause no interference with the coordinated schedule. 

Grant/Request Flag 

The Request Type indicates that a new Request is made of one or more other nodes. The No. Requests shall be 

non-zero in this case. The message may also contain Availabilities and Grants. 

The Grant Type indicates that one or more Grants are given or confirmed. The Num_Grants shall be non-zero 

in this case. The message may also contain Availabilities and Requests. Requests in this type of message 

indicate pending demand to the indicated node(s), but do not solicit a Grant from this node. 

This flag is always set to for coordinated distributed scheduling 

MSH-DSCH Sequence Counter 

Sequentially increased counter for solicit messages in uncoordinated scheduling (used as multiple solicits 
might be outstanding). In coordinated scheduling, it allows nodes to detect missed scheduling messages. 
Independent counters are used for the coordinated and uncoordinated messages. 
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4.3.20.1 MSH-DSCH Scheduling Information Element 

The Coordinated distributed scheduling information carried in the MSH-DSCH message, shown in table 51, shall be 
used to distribute information needed to determine transmission timing of the MSH-DSCH messages with coordinated 
distributed scheduling. Each node shall report the two related parameters both of its own and all its neighbours. 

Table 51 : MSH-DSCH Scheduling Information Element 



Syntax 


Size 


Notes 


MSH-DSCH Scheduling IE() { 






DSCH Schedule Info 
Next Xmt Mx 
Xmt Holdoff Exponent 


3 bits 
5 bits 




Num_SchedEntries 


8 bits 


Number of Neighbour MSH-DSCH Scheduling Entries 
in the message. 


for (1 = 0; i< Num SchedEntries; ++i) { 






NbrNodelD 


16 bits 


The Node ID of the neighbour being reported on. 


Nbr DSCH Schedule Info 
Nbr Next Xmt Mx 
Nbr Xmt Holdoff Exponent 


3 bits 
5 bits 


Advertise as reported by neighbour. 


} 







DSCH Schedule Info 

Xmt Holdoff Exponent 

The Xmt Holdoff Time is the number of MSH-DSCH transmit opportunities after Next Xmt Time (there are 
MSH-CTRL-LEN -1 opportunities per network control subframe, that this node is not eligible not transmit 
MSH-DSCH packets. 



Xmt Holdoff Time = 2^^'^'^°^'^°^^ Exponent+4) 



(8) 



Next Xmt Mx 

Next Xmt Time is the next MSH-DSCH eligibility interval for this neighbour and computed as the range 



2Xmt Holdoff Exponent ^ j^^^^ ^mt Mx < Next Xmt Time < 2^"^' ""''^"^ Exponent ^ ^^^^^ ^mt Mx + 1) 



(9) 



EXAMPLE: If Next Xmt Mx = 3 and Xmt Holdoff Exponent = 4, then the node shall be considered eligible for 
its next MSH-DSCH transmission between 49 and 64 (due to the granularity) transmission 
opportunities away and ineligible before that time. 

If the Next Xmt Mx field is set to OxlF (all ones), then the neighbour should be considered to be 
eligible to transmit from the time indicated by this value and every MSH-DSCH opportunity 
thereafter (i.e. treat Xmt Holdoff Time = 0). 
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4.3.20.2 MSH-DSCH Scheduling Information Element 

The Requests carried in the MSH-DSCH message shall convey resource requests on per link basis, as shown in table 52. 

Table 52: MSH-DSCH Request Information Element 



Syntax 


Size 


Notes 


MSH-DSCH Request lEQ { 






Link ID 


8 bits 


The ID assigned by the transmitting node to the link to 
this neighbour that this request involves. 


Demand Level 


8 bits 


Demand in minislots (assuming the current burst 
profile). 


Persistence 


3 bits 


Persistency field for demands. Number of frames over 

which the demand exists. 

= cancel reservation, 1 = single frame, 

2 = 2 frames, 3 = 4 frames, 

4 = 8 frames , 5 = 32 frames, 

6= 128 frames, 

7 = Good until cancelled or reduced. 


Reserved 


1 bits 




} 







4.3.20.3 MSH-DSCH Availability Information Element 

The Availabilities carried in the MSH-DSCH message shall be used to indicate free minislot ranges that neighbours 
could issue Grants in. Each Availability shall be indicated using the IE shown in table 53. 

Table 53: MSH-DSCH Availability Information Element 



Syntax 


Size 


Notes 


MSH-DSCH Availability IE() { 






Start Frame Number 


8 bits 


Indicates lowest 8 bits of frame number in which the 
availability starts. 


Minislot start 


8 bits 


The start position of the availability within the frame. 


Minislot Range 


7 bits 


The number of consecutive available minislots. 


Direction 


2 bits 


= Minislot range is unavailable. 

1 = Available for transmission in this minislot range. 

2 = Available for reception in this minislot range. 

3 = Available for either transmission or reception. 


Persistence 


3 bits 


Persistency field for Availabilities. Number of frames 

over which the Availability is valid. 

= cancel availability, 1 = single frame, 

2 = 2 frames , 3 = 4 frames, 

4 = 8 frames, 5 = 32 frames 

6 = 1 28 frames, 

7 = Good until cancelled or reduced. 


Channel 


4 bits 


Logical channel number on which the availability 
exists. 


} 
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4.3.20.4 



MSH-DSCH Grant Information Element 



The Grants carried in the MSH-DSCH message shall convey information, as shown in table 54, about a granted minislot 
range selected from the range reported as available. Grants shall be used both to grant and confirm a grant. 

Table 54: MSH-DSCH Grant Information Element 



Syntax 


Size 


Notes 


MSH-DSCH Grant IE{) { 






Link ID 




The ID assigned by the transmitting node to the 
neighbour that this Grant involves. 


Start Frame Number 


8 bits 


Indicates lowest 8 bits of frame number in which the 
Grant starts. 


Minislot start 


8 bits 


The start position of the Grant within the frame. 


Minislot Range 


7 bits 


The number of consecutive minislots granted. 


Direction 


2 bits 


= From requester to granter. 

1 = To requester from granter. 


Persistence 


3 bits 


Persistency field for Grants. Number of frames over 

which the Availability is valid. 

= cancel reservation, 1 = single frame, 

2 = 2 frames , 3 = 4 frames, 

4 = 8 frames, 5 = 32 frames, 

6 = 128 frames, 

7 = Good until cancelled or reduced. 


Channel 


4 bits 


Logical channel number on which the availability 
exists. 


} 







4.3.21 Type 42: MeSH-Centralized SCHeduling (MSH-CSCH) message 

A MeSH Centralized SCHeduling (MSH-CSCH) message shall be created by a mesh BS when using centralized 
scheduling. The BS shall broadcast the MSH-CSCH message, as shown in table 55, to all its neighbours, and all the 
nodes with hop count lower than HOPRANGE_THRESHOLD shall forward the MSH-CSCH message to their 
neighbours that have a higher hop count. In all these cases, the Grant/Request Flag = 0. HOPRANGE_THRESHOLD is 
a configuration value that need only be known to the mesh BS, as it can be derived by the other nodes from the 
MSH-CSCF message. 

Nodes can use MSH-CSCH messages to request bandwidth from the mesh BS setting the Grant/Request Flag = 1. Each 
node reports the individual traffic demand requests of each 'child' node in its subtree from the BS. The nodes in the 
subtree are those in the current scheduling tree to and from them mesh BS, known to all nodes in the network, and 
ordered by node ID. 
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Table 55: MSH-CSCH message format 



Syntax 


Size 


Notes 


MSH-CSCH Message Format() { 






MAC Management Message Type = 42 


8 bits 




MSH-CSCF Sequence Number 


3 bits 


Indicates the configuration, which shall be used to 
interpret this packet. 


Grant/Request Flag 


1 bit 


= Grant message (transmitted up the tree). 

1 = Request message (transmitted down the tree). 


Frame Schedule Flag 


1 bit 


If this flag is set, the allocation of flows shall occur over 
two frames, rather than one. 


Configuration Flag 


1 bit 




Reserved 


2 bits 




Num FlowEntries 


8 bits 




for (i = 0;i< Num FlowEntries; -i-i-i) { 






UL Flow 


4 bits 




If (Grant/Request Flag == 0) 






DL Flow 


4 bits 




} 






FlowScale Exponent 


4 bits 




Padding Nibble 


4 bits 


Pad till byte boundary. 


If (Grant/Request Flag == 1) { 






Num LinkUpdates 


4 bits 




for (i = 0;i< Num LinkUpdates; -i-i-i) { 






Node Index self 


8 bits 


Index self in MSH-CSCF list. 


Node Index parent 


8 bits 


Index parent in MSH-CSCF list. 


UL Burst Profile 


4 bits 


Burst Profile for transmitting up the tree. 


DL Burst Profile 


4 bits 


Burst Profile for transmitting down the tree. 


} 






} else { 




Sponsor Node Request. 


Sponsor Node 


8 bits 


index in MSH-CSCF list. 


DL Burst Profile 


4 bits 




UL Burst Profile 


4 bits 




} 






1 







Sponsor Node Request 

Three parameters (Sponsor Node, and Burst Profiles) shall be set to 0, except by nodes which wish to reserve 
an allocation for the "upper MAC initialization" as specified in clause 6.6.4. A node may only set these values 
if all its children report these values as 0. The Mesh BS shall in response provide a grant to Node Index 0x00, 
which shall be reserved for this purpose. 

Configuration Flag 

Indicates which centralized scheduling control message type (CSCH or CSCF) will be transmitted next by the 
Mesh BS. This bit may be set to aid the nodes in computing the validity of the schedule indicated in the current 

message (see clause 6.8.2). 

FlowScale Exponent 

Determines scale of the granted bandwidth. Its value typically depends on the number of nodes in the network, 

the achievable PHY bitrate, the traffic demand and the provided service. 

For the DL, this gives the absolute values of flow granted, so the total minislot range allowed for centralized 

scheduling need not be used if not needed, with the remainder set aside for distributed scheduling. 

For the UL, the lowest exponent possible is used at each hop, with quantization of forwarded requests rounded 

up (e.g. avoids reducing any requests to zero). 

NumFlo wEntrie s 

Number of 8-bit assignment fields followed, ordered according to appearance in MSH-CSCF. This number 
shall match the number of entries in the most recent MSH-CSCF message. 
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UL_Flow 

DL_Flow 

Base of the granted/requested bandwidth as bits/s for DL respectively UL traffic of the node in the BS's 
scheduhng tree. The flow only indicates traffic that initiates or terminates in the node itself (i.e. forwarded 
traffic is not included), except for traffic forwarded from/to nodes not part of the MSH-CSCF tree. The actual 
granted/requested bandwidth shall be calculated as: 

BWuL =UL_Flowx(2P^°*^'=^''=E''P°"'="'+'4) ^-^^/^ 
BWdl =DL_Flowx(2P'°*^'=^''=E''P™™'+l^) bits/s 

The assignments in the list are ordered according to the order in the MSH-CSCF message. 

Num_LinkUpdates 

Link updates are inserted by the mesh BS if the number of link tree changes does not warrant a MSH-CSCF 
broadcast. The mesh BS shall repeat the link update in every MSH-CSCH either until the update becomes 
invalid, or until the change is reflected in a MSH-CSCF message. 



(10) 



4.3.22 Type 43: MeSH-Centralized Scheduling ConFiguration (MSH-CSCF) 
message 

A MeSH Centralized Scheduling ConFiguration (MSH-CSCF) message shall be broadcast in mesh mode when using 
centralized scheduling. The mesh BS shall broadcast the MSH-CSCF message, as shown in table 56, to all its 
neighbours, and all nodes shall forward (rebroadcast) the message according to its index number specified in the 

message. 

Table 56: MSH-CSCF message format 



Syntax 


Size 


Notes 


MSH-CSCF Message FormatQ { 






MAC Management Message Type = 43 


8 bits 




MSH-CSCF Sequence Number 


4 bits 


The BS shall increment this number by one for every 
MSH-CSCF message it transmits. 


Num_Channels 


4 bits 


Number of channels available for centralized 
scheduling. 


for (i = 0;i< Num_Channels; ++i) { 
Logical Channel Number 


4 bits 


The logical index of the Physical channel, as reported 
in MSH-NCFG Network Descriptor. 


Padding nibble 


0/4 bits 


Pad till byte boundary. 


Num Nodes 


8 bits 




for (i = 0;i< Num Nodes; ++i) { 






Node ID 


16 bits 


Unique node identifier assigned to node. 


Num Children 


8 bits 




for (j = 0;j< Num Children; ++j) { 






Child Index 


8 bits 


Index child in Node list. 


UL Burst Profile 


4 bits 


Burst Profile for transmitting up the tree from this child. 


DL Burst Profile 


4 bits 


Burst Profile for transmitting down the tree to this child. 


} 






1 






} 
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4.3.23 Type 44/45: AAS-FeedBaCK REQuest/ReSPonse (AAS-FBCK 
REQ/RSP) message 

AAS Feedback messages as shown in table 57 and table 58 are used to obtain channel state information as described in 
clause 7.4. 

Table 57: AAS-FeedBaCK REQuest (AAS-FBCK-REQ) message format 



Syntax 


Size 


Notes 


AAS Feedback Request Message Format() { 






Management Message Type = 44 


8 bits 




Frame Number 


24 bits 




Number of Frames 


7 bits 




Measurement Data Type 


1 bits 


= measure on DL preamble only 

1 = measure on DL data (for this SS) only 


Feedback Request Counter 


6 bits 




Frequency Measurement 
Subcarrier Resolution 


2 bits 


ObOO= 4 
Ob01 = 8 
0b10 = 16 
Ob1 1 = 32 


} 







Frame Number 

The Frame Number in which the measurement shall be started. 

Number of Frames 

The number of frames over which the measurement shall be averaged. 

Frequency Measurement Subcarrier Resolution 

Indicates the frequency measurement points to report on. Measurement points shall be on the frequencies 
corresponding to the negative subcarrier offset indices -N^j,gy2 plus n times the indicated subcarrier resolution 

and corresponding to the positive subcarrier offset indices Nuj,gy2 minus n times the indicated subcarrier 

resolution where n a positive integer. See TS 102 177 [3], clause 4.2. 

Feedback Request Counter 

Increased by one every time an AAS-FBCK-REQ is sent to the SS. Individual counters shall be maintained for 
each SS. 

Table 58: AAS-FeedBaCK-ReSPonse (AAS-FBCK-RSP) message format 



Syntax 


Size 


Notes 


AAS Feedback Response Message Format() { 






Management Message Type = 45 


8 bits 




Reserved 


2 bits 


Set to ObOO 


Feedback Request Counter 


6 bits 




for (i = 0; i<Number of Frequencies; i++) { 




According to Frequency Measurement Subcarrier 
Resolution 


Re(Frequency[i]) 


8 bits 




lm(Frequency[i]) 


8 bits 




1 






} 







Feedback Request Counter 

Counter from the AAS-FBCK-REQ messages to which this is the response. 

Frequency 

The real (Re) and imaginary (Im) part of the measured amplitude on the frequency measurement point (low to 
high frequency) in signed integer fixed point format ([±][4 bits]. [4 bits]. 
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4.3.24 Type 46-255: DUMMY message 

A SS shall be capable of decoding the DUMMY message shown in table 59. A BS shall not transmit this message 
unless in test mode. A SS shall not transmit this message. 

Table 59: DUMMY message format 



Syntax 


Size 


Notes 


DUMMY Message FormatQ { 






Management Message Type = 46. ..255 


8 bits 




Length 


8 bits 




Unspecified data 


Length x8 bits 




} 







Length 

The Length in bytes of the following 'Unspecified data'. 



Automatic Repeat reQuest (ARQ) 



The ARQ mechanism is an optional part of the MAC layer and can be enabled on a per-connection basis. The 
per-connection ARQ and associated parameters shall be specified and negotiated during connection creation or change. 
A connection cannot have a mixture of ARQ and non-ARQ traffic. Similar to other properties of the MAC protocol the 
scope of a specific instance of ARQ is limited to one unidirectional connection. 

Connections are set and defined dynamically through the DS A/DSC class of messages. CRC-32 shall be used for error 
detection of PDUs for all ARQ-enabled connections. All ARQ parameters (see clause 5.2) shall be set and all ARQ 
variables (see clause 5.3) shall be reset (set to 0) on connection setup. 

ARQ feedback information can be sent as a standalone MAC management message (see table 30) on the appropriate 
basic management connection, or can be piggybacked on an existing connection using the ARQ Feedback Payload 
(see table 60). ARQ Feedback shall not be fragmented. 

5.1 Packing for ARQ-enabled connections 

The use of packing subheaders for ARQ-enabled connections is similar to that for non-ARQ connections, except that 
ARQ-enabled connections set bit#3 in the general MAC header's Type field (see table 1). MAC PDUs transmitted at 
ARQ-enabled connections must have either Fragmentation Subheader or Packing Subheaders to provide each payload 
with block sequence numbers information. If packing is turned on for a connection, the MAC may pack multiple MAC 
SDUs into a single MAC PDU. The transmitting side has full discretion whether or not to pack a group of MAC SDUs 
and/or fragments in a single MAC PDU. Depending on the ARQ policies, the transmitter may choose to pack multiple 
fragments of the same SDU into a single MAC PDU, even if there is sufficient bandwidth to send the whole MAC PDU 
un-fragmented. 

The packing of variable-length MAC SDUs for the ARQ-enabled connections is similar to that of non-ARQ 
connections, when fragmentation is enabled. The BSN of the Packing Subheader shall be used by the ARQ protocol to 
identify and retransmit lost fragments. The primary difference between ARQ and non-ARQ packing is in the interaction 
with fragmentation. 

5.1 .1 Interaction of packing with fragmentation 

For ARQ-enabled connections, when the general MAC header's Type (see table 1) indicates packing is used (i.e. when 
bit#5 is set) , fragmentation information for each individual MAC SDU or MAC SDU fragment is contained in the 
associated Packing Subheader. 

When the Type field indicates that packing is not used, fragmentation information for the MAC PDU's single payload 
(MAC SDU or MAC SDU fragment) is contained in the Fragmentation Subheader. Each of the packed MAC SDU or 
MAC SDU fragments or ARQ feedback payload shall have its own packing subheader and some of them may be 
transmissions while others are re-transmissions. 
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5.1 .2 Packing ARQ Feedback Information Elements 

An ARQ Feedback Payload (see table 60) consists of one or more ARQ Feedback Information Elements (see table 61). 
The ARQ Feedback Payload may be sent on an ARQ or non-ARQ connection. However, policies based on 
implementation and/or QoS constraints may restrict the use of certain connections for transporting the ARQ Feedback 
Payload. The ARQ Feedback Payload is treated like any other payload (SDU or fragments) from the packing 
perspective, except that only one ARQ Feedback Payload shall be present within a single MAC PDU. 

Table 60: ARQ Feedback Payload 



Syntax 


Size 


Notes 


ARQ Feedback Payload { 






do 






ARQ Feedback lE(last) 


variable 


Insert as many as desired, until last == TRUE 


until (last) 






1 







The presence of an ACK Feedback Payload in a MAC PDU is indicated by the value of bit #4 of the Type field in the 
generic MAC header. When present, the first packed payload shall be the ARQ Feedback Payload. The Packing 
Subheader preceding the ARQ Feedback Payload indicates the total length of the payload including the Packing 
Subheader and all ARQ Feedback Information Elements within the payload. The FSN/BSN field of the Packing 
Subheader shall be ignored for the ARQ Feedback Payload and the EC bits shall be set to ObOO. 

Table 61 : ARQ Feedback Information Element 



Syntax 


Size 


Notes 


ARQ feedback IE (last) { 


variable 




CID 


16 bits 


The ID of the connection being referenced. 


Last 


1 bit 


= More ARQ feedback IE in the list. 

1 = Last ARQ feedback IE in the list. 


ACK Type 


2 bit 


0x0 = Selective ACK entry, 

0x1 = Cumulative ACK entry, 

0x2 = Cumulative with Selective ACK entry, 

0x3 = Reserved. 


BSN 


1 1 bits 


If (ACK Type == 0x0): BSN value corresponds to the 
most significant bit of the first 16-bit ARQ ACK map. 
If (ACK Type == 0x1): BSN value indicates that its 
corresponding block and all blocks with lesser values 
within the transmission window have been successfully 
received. 

If (ACK Type == 0x2): Combines the functionality of 
ACK Types 0x0 and 0x1 . 


Num_ACK_Maps 


2 bits 


If ACK Type == 01 , the field is reserved and set to 00. 
Otherwise the field indicates the number of ACK maps: 
0x0 = 1 , 
0x1 = 2, 
0x2 = 3, 
0x3 = 4. 


if (ACK Type! = 01 ){ 






for (i = 0; i< NUM ACK Maps + 1 ; ++i) 






ACK Map 


1 6 bits 


Each bit set to one indicates the corresponding ARQ 
block has been received without errors. The bit 
corresponding to the BSN value in the IE, is the most 
significant bit of the first map entry. The bits for 
succeeding block numbers are assigned left-to-right 
(msb to Isb) within the map entry. 
If the ACK Type is 10, then the most significant bit of 
the first map entry shall be set to one and the IE shall 
be interpreted as a cumulative ACK for the BSN value 
in the IE. The rest of the bitmap shall be interpreted 
similar to ACK Type 00. 


} 
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5.2 ARQ parameters 



ARQ_BLOCK_SIZE 

ARQ_BLOCK_SIZE is the basic retransmission unit and it should be negotiated during connection setup. The 
concept of blocks is described in clause 5.4. 

ARQ_BSN_MODULUS 

ARQ_BSN_MODULUS is equal to the number of unique BSN values, i.e. 2 048. 

ARQ_WINDOW_SIZE 

ARQ_WINDOW_SIZE is the maximum number of the unacknowledged ARQ blocks at any given time, 
which shall be less than or equal to half of ARQ_BSN_MODULUS. An ARQ block is unacknowledged if it 
has been transmitted but no acknowledgement has been received. 

ARQ_BLOCK_LIFETIME 

ARQ_BLOCK_LIFETIME is the maximum time interval beyond which a transmitter shall discard 
unacknowledged ARQ blocks. 

ARQ_RETRY_TIMEOUT 

ARQ_RETRY_TIMEOUT is the minimum time interval a transmitter shall wait before retransmitting an 
unacknowledged ARQ block. 

ARQ_SYNC_LOSS_TIMEOUT 

ARQ_SYNC_LOSS_TIMEOUT is the length of a time interval from last transmitted/received SDU, in which 
at least one MAC PDU was transmitted/received with no change in the position of ARQ Tx/Rx window, after 
this time interval passed, ARQ synchronization shall be considered lost. 

5.3 ARQ variables 

ARQ_TX_WINDOW_START 

All BSN up to (ARQ_TX_WINDOW_START - 1) have been acknowledged. 

ARQ_TX_NEXT_BSN 

BSN of the next block to send. This value shall be between ARQ_TX_WINDOW_START and 
(ARQ_TX_WINDOW_START + ARQ_WINDOW_SIZE). 

ARQ_RX_WINDOW_START 

All BSN up to (ARQ_RX_WINDOW_START - 1) have been correctly received. 

ARQ_RX_HIGHEST_BSN 

BSN of the highest block received, plus one. This value shall be between ARQ_RX_WINDOW_START and 
(ARQ_RX_WINDOW_START + ARQ_WINDOW_SIZE). 

5.4 ARQ operation 
5.4.1 ARQ block usage 

The clause describes the use of blocks for ARQ. A MAC SDU is logically divided into blocks of given. 

ARQ_BLOCK_SIZE. The last block of a MAC SDU may be smaller than ARQ_BLOCK_SIZE. Once defined, the 
block never changes. 

This value of the ARQ_BLOCK_SIZE TLV specifies the ARQ block size. This parameter is negotiated upon 
connection setup. The DSA-REQ shall contain the suggested value of this parameter. The DSA-RSP message shall 
contain the confirmation value or an alternate value for this parameter. 

A set of blocks selected for transmission or retransmission is encapsulated into a PDU. A PDU may contain blocks that 
are transmitted for the first time as well as retransmitted blocks. If fragmentation is enabled for this connection, the 
fragmentation shall occur only on ARQ block boundaries. If a PDU is not packed, all the blocks in that PDU must have 
contiguous block numbers. When a PDU is packed, any sequence of blocks between MAC subheaders and the sequence 
of blocks after the last packing subheader must have contiguous block numbers. 
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If ARQ is enabled at the connection, Fragmentation and Packing subheaders contain a BSN, which is the sequence 
number of the first ARQ block in the sequence of blocks following this subheader. It is a matter of transmitter's policy 
whether a set of blocks once transmitted as a single PDU should be retransmitted also as a single PDU or not. Figure 
NNN illustrates the use of blocks for ARQ transmissions and retransmissions; two options for retransmission presented: 
with and without rearrangements of blocks. 
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Figure 1 : Block usage examples for ARQ transmissions and retransmissions 



5.4.2 Comparison of BSNs 

As numbers assigned to blocks occasionally wrap around zero, BSNs cannot be compared by directly comparing their 
values. Instead, both BSNs need to be normalized before a comparison can be made. Normalization of a BSN on the 
transmit side is accomplished using the expression: 



[Tx side: bsn„ = (bsn - ARQ_TX_WINDOW_START),„„, arq_bsn_modulus 
I Rx side: bsn„ = (bsn - ARQ_RX_WINDOW_START)„„, arq_bsn_modulus 



(11) 
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5.4.3 Transmitter state machine 

An ARQ block may be in one of the following four states: Not-sent, Outstanding, Discarded, Waiting-for-retransmit or 
Done. Any ARQ block begins as Not-sent, and transfers to other states as shown in figure 2. 

For a given connection, the transmitter shall first handle (transmit or discard) blocks in Waiting-for- retransmit state and 
only then blocks in Not-sent state. Blocks in Outstanding, Discarded, or Done state shall not be transmitted. When 
blocks are retransmitted, the block with the lowest FSN shall be retransmitted first. 

When a block in not-sent state is included in a MAC PDU, it is assigned the current value of ARQ_TX_NEXT_BSN, 
which is then incremented. 




ARQ_FRAGMENT_LIFETIME 



Figure 2: Transmitter ARQ state machine 

When any acknowledgement is received, the transmitter shall check the validity of the BSN(s). A BSN is valid if: 
< BSN- ARQ_TX_WINDOW_START < ARQ_TX_NEXT_BSN-ARQ_TX_WINDOWN_START 

If the BSN is invalid, the transmitter shall ignore the acknowledgement. All timers associated with acknowledged 
blocks shall be cancelled. 

When a cumulative acknowledgement (ACK Type == OxO)with a valid BSN is received, the transmitter shall consider 
all blocks in the interval ARQ_TX_WINDOW_START to BSN (inclusive) as ACK-ed and set 
ARQ_TX_WINDOW_START to BSN+1. 

When a selective acknowledgement (ACK TYPE == 0x1) is received, the transmitter shall validate all BSNs indicated 
by the acknowledgement entries in the bitmap, and consider all such valid BSNs as ACK-ed. As the bitmap entries are 
processed in increasing BSN order, ARQ_TX_WINDOW_START shall be incremented each time the BSN of an 
acknowledged fragment equals ARQ_TX_WINDOW_START. 

When ARQ_TX_WINDOW_START has been advanced by either of the above methods and acknowledgement of 
reception has already been received for the fragment with the BSN value now assigned to 

ARQ_TX_WINDOW_START, the value of ARQ_TX_WINDOW_START shall be incremented until a BSN value is 
reached for which no acknowledgement has been received. 

A bitmap entry not indicating acknowledged that has a BSN lower than a bitmap entry which does indicate 
acknowledged shall be considered a NACK for the corresponding block. A not acknowledged bit map entry may also be 
considered a NACK if sufficient time elapsed before the feedback IE was transmitted to allow the receiver to receive 
and process the corresponding block. 

When a cumulative with selective acknowledgement (ACK TYPE == 0x2) with a valid BSN is received, the transmitter 
performs the actions described above for cumulative acknowledgement, followed by those for a selective 
acknowledgement. 
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An ARQ Discard message shall be sent when a block reaches Discard state. The message may be sent immediately or 
may be delayed up to ARQ_RX_PURGE_TIMEOUT + ARQ_RETRY_TIMEOUT. Following the first transmission, 
subsequent discard orders shall be sent to the receiver at intervals of ARQ_RETRY_TIMEOUT until an 
acknowledgement to the discarded BSN has been received. Discard orders for adjacent BSN values may be 
accumulated in a single Discard message. 

5.4.4 Receiver state machine 

When a PDU is received, its integrity shall be determined based on the CRC-32 checksum. If a PDU passes the 
checksum, it is unpacked and de -fragmented, if necessary. The receiver maintains a sliding-window defined by 
ARQ_RX_WINDOW_START state variable and the ARQ_WINDOW_SIZE parameter. When an ARQ block with a 
number that falls in the range defined by the sliding window is received, the receiver shall accept it. ARQ block 
numbers outside the sliding window shall be rejected. The receiver should discard duplicate ARQ blocks (i.e. ARQ 
blocks that where already received correctly) within the window. 

As each block is received, a timer is started for that block. When the value of the timer for a block exceeds 
ARQ_RX_PURGE_TIMEOUT, the timeout condition is marked. When this occurs, ARQ_RX_WINDOW_START is 
advanced to the BSN of the next block not yet received after the marked block. Timers for delivered blocks remain 
active and are monitored for timeout until the BSN values are outside the receive window. 

When ARQ_RX_WINDOW_START is advanced, any BSN values corresponding to blocks that have not yet been 
received residing in the interval between the previous and current ARQ_RX_WINDOW_START value shall be marked 
as received and the receiver shall send an ARQ Feedback IE to the transmitter with the updated information. Any 
blocks belonging to complete SDUs shall be delivered. Blocks from partial SDUs shall be discarded. 

When a discard message is received from the transmitter, the receiver shall discard the specified blocks, advance 
ARQ_RX_WINDOW_START to the BSN of the first block not yet received after the BSN provided in the Discard 
message, and mark all not received blocks in the interval from the previous to new ARQ_RX_WINDOW_START 
values as received for ARQ feedback IE reporting. 

For each ARQ block received, an acknowledgment shall be sent to the transmitter. Acknowledgment for blocks outside 
the sliding window shall be cumulative. Acknowledgments for blocks within the sliding window may be either for 
specific ARQ blocks (i.e. contain information on the acknowledged ARQ block numbers), or cumulative (i.e. contain 
the highest ARQ block number below which all ARQ blocks have been received correctly) or a combination of both 
(i.e. cumulative with selective). Acknowledgments shall be sent in the order of the ARQ block numbers they 
acknowledge. The frequency of acknowledgement generation is not specified here and is implementation dependent. 

A MAC SDU is ready to be handed to the upper layers when all of the ARQ blocks of the MAC SDU have been 
correctly received within the time-out values defined. 

When ARQ_DELIVER_IN_ORDER is enabled, a MAC SDU is handed to the upper layers as soon as all the ARQ 
blocks of the MAC SDU have been correctly received within the defined time-out values and all blocks with sequence 
numbers smaller than those of the completed message have either been discarded due to time-out violation or delivered 
to the upper layers. 

When ARQ_DELIVER_IN_ORDER is not enabled, MAC SDUs are handed to the upper layers as soon as all blocks of 
the MAC SDU have been successfully received within the defined time-out values. 
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Figure 3: ARQ block reception 

5.4.5 Resetting the ARQ state machine 

Synchronization of the ARQ state machines is governed by timers managed by the transmitter and receiver state 
machine. Each time ARQ_TX_WINDOW_START is updated, the transmitter timer is reset (set to zero). Each time 
ARQ_RX_WINDOW_START is updated, the transmitter timer is reset. 

When the timer exceeds the value of ARQ_SYNC_LOSS_TIMEOUT the state machine shall initiate the ARQ Reset 
process for that connection. The process of executing an ARQ Reset on a connection is shown in figures 4 and 5. 
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Figure 4: Receiver initiated ARQ Reset 
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Figure 5: Transmitter initiated ARQ Reset 



5.5 ARQ service flow TLVs 

The following TLV encodings shall be available. 

ARQ SUPPORT 

The ARQ SUPPORT indicates whether or not ARQ is supported by the system. When the system supports 
ARQ, this TLV shall be included in the REG-REQ by the SS whereas the BS shall indicate acceptance or 
rejection of the ability. ARQ shall be available for connections only if both sides support it. 

ARQ ENABLE 

The ARQ ENABLE TLV indicates whether or not ARQ is available for the connection that is being setup. The 
DSA-REQ shall contain the request to use ARQ or not. The DSA-RSP message shall contain the acceptance or 
rejection of the request. ARQ shall be enabled for this connection only if both sides support it. When a 
DSA-REQ is issued by the BS, the use of ARQ may be mandated for the requested connection (if ARQ 
availability was confirmed during registration). In that case, the SS shall either reject the connection or accept 
the connection with ARQ. 
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ARQ WINDOW SIZE 

This parameter is negotiated upon connection setup. The DSA-REQ/DSC-REQ message shall contain the 
suggested value for this parameter. The DSA-RSP/DSC-RSP message shall contain the confirmation value or 
an alternate value for this parameter. The smaller of the two shall be used as the actual 
ARQ_WINDOW_SIZE. 

ARQ RETRY TIMEOUT 

The ARQ retry timeout should account for the transmitter and receiver processing delays and any other delays 
relevant to the system. This is achieved through the use of the following two TLVs: 

ARQ_TX_DELAY: This is the total estimated transmitter delay, including sending (e.g. MAC PDUs) 
and receiving (e.g. ARQ feedback) delays and other implementation dependent processing delays. If the 
transmitter is the BS, it may include other delays such as scheduling and propagation delay. 

ARQ_RX_DELAY: This is the total estimated receiver delay, including receiving (e.g. MAC PDUs) and 
sending (e.g. ARQ feedback) delays and other implementation dependent processing delays. If the 
receiver is the BS, it may include other delays such as scheduling and propagation delay. 

The DSA-REQ and DSA-RSP messages shall contain the values for these parameters, where the receiver and 
transmitter each declare their capabilities. When the DSA handshake is completed, each party shall calculate: 

ARQ_RETRY_TIMEOUT = ARQ_TX_DELAY + ARQ_RX_DELAY 

ARQ BLOCK LIFETIME 

The BS shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter as set by the BS. If this parameter is set to 0, then the ARQ_BLOCK_LIFETIME value shall be 
considered infinite. 

ARQ_S YNC_LOS S_TIMEOUT 

The BS shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter as set by the BS. If this parameter is set to 0, then the ARQ_SYNC_LOSS_TIMEOUT value shall 
be considered infinite. 

ARQ_DELIVER_IN_ORDER 

The transmitter shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter. This TLV indicates whether or not data is to be delivered by the receiving MAC to its client 
application in the order in which the data was handed off to the originating MAC. 

ARQ_RX_PURGE_TIMEOUT 

The BS shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter as set by the BS. If this parameter is set to 0, then the ARQ_RX_PURGE_TIMEOUT value shall be 
considered infinite. 
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Table 62: ARQTLVs 



Name 


Type 


Length 


Value 


Scope 


ARQ_SUPPQRT 


5.21 


1 


0: No ARQ support capability 
1-254: IVIax. simultaneous connections for 

which ARQ can be supported 
255: 255 or more simultaneously 

supportable ARQ connections 


REG-REQ 
REG-RSP 


ARQ_ENABLE 


[24/25]. 11 


1 


= ARQ not support 

1 = ARQ supported 

2 = ARQ mandated (BS in DSA-REQ only) 


DSA-REQ 
DSA-RSP 


ARQ_WINDOW_SIZE 


[24/25]. 12 


2 


1 -{ARQ_BSN_MQDULUS/2) 


DSx-REQ 
DSx-RSP 


ARQ_TX_DELAY 


[24/25]. 13 


2 


Estimated transmitter delay 
- 655 350 (10 |js granularity) 


DSA-REQ 
DSA-RSP 


ARQ_RX_DELAY 


[24/25]. 22 


2 


Estimated receiver delay 

- 655 350 (10 MS granularity) 


DSA-REQ 
DSA-RSP 


ARQ_BLQCK_LIFETIME 


[24/25]. 17 


2 


= Infinite 

1 -655 350 (10 MS granularity) 


DSA-REQ 
DSA-RSP 


ARQ_SYNC_LOSS_TIMEOUT 


[24/25]. 19 


2 


= Infinite 

1 -655 350 (10 MS granularity) 


DSA-REQ 
DSA-RSP 


ARQ_DELIVER_IN_QRDER 


[24/25]. 20 


1 


= Order of delivery is not preserved 

1 = Qrder of delivery is preserved 


DSA-REQ 
DSA-RSP 


ARQ_RX_PURGE_TIMEOUT 


[24/25]. 21 


2 


= Infinite 

1 - 655 350 (10 MS granularity) 


DSA-REQ 
DSA-RSP 


ARQ_BLQCK_SIZE 


[24/25].22 


1 


Length of ARQ block, bytes 


DSA-REQ 
DSA-RSP 



Mesh topology support 



6.1 



Introduction 



The main difference between the PMP and optional Mesh modes is that in the PMP mode, traffic only occurs between 
the BS and SSs, while in the Mesh mode traffic can be routed through other SSs and can occur directly between SSs. 
Depending on the transmission protocol algorithm used, sharing of channel resources can be done on the basis of 
equality using distributed scheduling, or on the basis of superiority of the mesh BS, which effectively results in 
centralized scheduling, or on a combination of both. 

Where optional mesh systems are addressed, a system consists of an MAC and PHY implementation with at least two 
mesh nodes communicating via a multipoint-to-multipoint radio air interface, along with the interfaces to external 
networks and services transported by the MAC and PHY. 

Within a mesh network, a system that has a direct connection to backhaul services outside the mesh network, is termed 
a mesh BS. All the other systems of a mesh network are termed mesh SS. In general, the systems of a mesh network are 
termed nodes. Within mesh context, uplink and downlink are defined as traffic in the direction of the mesh BS and 
traffic away from the mesh BS respectively. 

The other three important terms of mesh systems are neighbour, neighbourhood and extended neighbourhood. The 
stations with which a node has direct links are called neighbours. Neighbours of a node shall form a neighbourhood. A 
node's neighbours are considered to be 'one hop' away from the node. An extended neighbourhood contains, 
additionally, all the neighbours of the neighbourhood. 

Using distributed scheduling, all the nodes including the mesh BS shall coordinate their transmissions in their two-hop 
neighbourhood and shall broadcast their schedules (available resources, requests and grants) to all their neighbours. 
Optionally the schedule may also be established by directed un-coordinated requests and grants between two nodes. 
Nodes shall ensure that the resulting transmissions do not cause collisions with the data and control traffic scheduled by 
any other node in the two-hop neighbourhood. There is no difference in the mechanism used in determining the 
schedule for downlink and uplink. 
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In the mode of operation with centralized scheduHng, resources are granted in a more centralized manner. The mesh BS 
shall gather resource requests from all the mesh SSs within a certain hop range. It shall determine amount of granted 
resources for each link in the network both in downlink and uplink, and communicates these grants to all the mesh SSs 
within the hop range. The grant messages do not contain the actual schedule but each node shall compute it by using the 
predetermined algorithm with given parameters. 

All the communications are in the context of a link, which is established between two nodes. One link shall be used for 
all the data transmissions between the two nodes. QoS is provisioned over links on a message by message basis. No 
service or QoS parameters are associated with a link but each unicast message has service parameters in the header. 
Traffic classification and flow regulation are performed at ingress node by upper-layer classification/regulation 
protocol. The service parameters associated with each message shall be communicated together with the message 
content via the MAC SAP. 

Mesh systems typically use omni directional or 360° steerable antennas, but can also be co-located using sector 
antennas. At the edge of the coverage area of the mesh network, where only a connection to a single point is needed, 
even highly directional antennas can be used. 



6.2 Addressing and connections 



Each node shall have a 48-bit universal MAC address. The address uniquely defines the node from within the set of all 
possible vendors and equipment types. This address is used during the network entry process and as part of the 
authorization process by which the candidate node and the network verify the identity of each other. 

When authorized to the network the candidate node shall receive a 16-bit Node Identifier (Node ID) upon a request to 
the mesh BS. Node ID is the basis for identifying nodes during normal operation. The Node ID is transferred in the 
Mesh subheader, which follows the Generic MAC header, in both unicast and broadcast messages. 

For addressing nodes in the local neighbourhood, 8-bit link identifiers (Link IDs) shall be used. Each node shall assign 
an ID for each link it has established to its neighbours. The Link IDs are communicated during the Link Establishment 
process as neighbouring nodes establish new links. The Link ID is transmitted as part of the CID in the Generic MAC 
header in unicast messages. The Link IDs shall be used in distributed scheduling to identify resource requests and 
grants. Since these messages are broadcast, the receiver nodes shall be able to identify the schedule of their own using 
both the transmitter's Node ID in the Mesh subheader, and the Link ID in the MSH-DSCH payload. 

After entering the network, a node can establish links with nodes other than its sponsor by following the secure process 
as defined in table 63. This process uses the MSH-NCFG Neighbour Link Establishment IE (see table 48). 

1) Node A sends a challenge (action code = 0x0) containing: 

HM AC { Operator Shared Secret, frame number. Node ID of node A, Node ID of node B } (12) 

in which the Operator Shared Secret is a private key obtained from the provider (which is also used to enter the 
network) and the frame number is the last known frame number in which Node B send a MSH-NCFG 

message. 

2) Node B, upon reception, computes the same value (it may also attempt some earlier frame numbers in which it 
sent MSH-NCFG messages, in case node A missed the last of its MSH-NCFGs) as above and compares. If the 
values do not match, a rejection (action code = 0x3) is returned. If a match is achieved. Node B sends, 
implicitly accepting the link, a challenge response (action code = 0x1) containing: 

HMAC{Operator Shared Secret, frame number. Node ID of node B, Node ID of node A} (13) 

in which the frame number is the frame number in which Node A sent the MSH-NCFG message with 
challenge. It also randomly selects and includes an unused link ID, which shall from this point forward 
indicate the link from node B to node A. 

3) Node A, upon reception, computes the same value as above and compares. If the values do not match a 
rejection (action code = 0x3) is returned. If a match is achieved. Node A sends an Accept. It also randomly 
selects and includes an unused link ID, which shall from this point forward indicate the link from node A to 
node B. 
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Table 63: Link establishment 



Node A 




NodeB 


Send MSH-NCFG 






Neighbour Link Establishment IE 






Action Code = Challenge 


Challenge 


— >• 

If (HMAC match (see eq. 12)) 
send MSH-NCFG 
Neighbour Link Establishment IE 
Action Code = Challenge Response 




< Challenge Response - 


newLinklDB^A 


If (HMAC match (see eq. 13)) 






send MSH-NCFG 






Neighbour Link Establishment IE 






Action Code = Accept 






new Link ID A -^ B 




■w 







The Connection ID in mesh mode is specified as shown in table 64 to convey broadcast/unicast, service parameters and 
the link identification. 

Table 64: Connection ID 



Syntax 


Size 


Notes 


CIDO { 






if (Xmt Link ID == OxFF) { 






Logical Network ID 


8 bits 


0x00 All-net Broadcast 


} else { 






Type 


2 bits 


0x0 MAC Management 

0x1 IP 

0x2-0x3 Reserved 


Reliability 


1 bit 


0x0 No retransmissions 
0x1 Up to 4 retransmissions 


Priority/Class 


3 bits 


Indicates message class. 


Drop Precedence 


2 bits 


Messages with larger Drop Precedence shall have 
higher dropping likelihood during congestion. 


} 






Xmt Link ID 


8 bits 


OxFF MAC management broadcast 


1 







6.3 



MAC service definition 



6.3.1 Primitives 

The following primitives are supported at the MAC Service Access Point in mesh mode: 
MAC_CREATE_CONNECTION.indication 
MAC_CHANGE_CONNECTION.indication 
MAC_TERMINATE_CONNECTION.request 
MAC_TERMINATE_CONNECTION.indication 
MAC_DATA.request 
MAC_DATA.indication 
MAC_FORWARDING_UPDATE.request 
MAC FORWARDING UPDATE.indication 
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In mesh mode none of the actions cause the initiating CS to send a REQUEST primitive to its MAC sublayer. They are 
either indications of the resuhs from the processes handled by the MAC CPS management entity, or data delivery 
actions needed to convey information to the peer CS. 

6.3.2 MAC_CREATE_CONNECTION. indication 

Function: 

This primitive is issued by a MAC entity to the CS, to report a new link established to a neighbour node. 

Generation: 

This primitive is generated whenever a new link has been established to a neighbour node. 

Effect of receipt: 

The receipt of the primitive is an indication to the CS that a link to the given neighbour node is up and can be 
used for data delivery. 

Semantics: 

MAC_CREATE_CONNECTION.indication 

{ 

CID, 

max length, 

service flow parameters, 

encryption flag 



The CID is the Connection ID in Mesh as conveyed in the Generic MAC header. 
The max length parameter specifies the maximum length of SDUs that are allowed over the link. 
The service flow parameters include information on: 
Data rate (Mbps) 

Data rate associated with the burst profile for the physical link over which the connection is created. 
Transmit power (dB) 

Transmit power at the antenna port for the physical link over which the connection is created. 

Estimate of packet error rate for 256-byte packets 

The encryption flag specifies that the data carried over this link is encrypted, if ON, If OFF, then no 
encryption is used. 

6.3.3 MAC_CHANGE_CONNECTION. indication 

Function: 

This primitive is issued by a MAC entity to the CS, to report new parameters of an existing link to a neighbour 
node. 

Generation: 

This primitive is generated whenever parameters of an existing link has changed. 

Effect of receipt: 

The CS shall take into account new link parameters in the use of the link. 

Semantics: 

MAC_CHANGE_CONNECTION.indication 
{ 
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CID, 

max length, 
service parameters, 
encryption flag 



The CID is the Connection ID in Mesh as conveyed in the Generic MAC header. 

The max length parameter specifies the maximum length of SDUs that are allowed over the link. 
The service parameters include information on; 

Target data rate for the link in Mbps. 

Transmit energy for the link. 

Estimate of packet error rate for 256-byte packets. 

The encryption flag specifies that over this link encryption is possible, if ON, If OFF, then no encryption 

is possible. 

6.3.4 MAC_TERMINATE_CONNECTION. request 

Function: 

This primitive is issued by a CS, to terminate an existing link to a neighbour node. 

Generation: 

This primitive is generated to bring down an existing link to a neighbour node. 

Effect of receipt: 

The receipt of the primitive causes the MAC to terminate the connection and report that to the MAC entity in 
the neighbour the link was to. 

Semantics: 

MAC_TERMINATE_CONNECTION.request 

{ 

CID 



The CID is the Connection ID in Mesh as conveyed in the Generic MAC header. 

6.3.5 MAC_TERMINATE_CONNECTION. indication 

Function: 

This primitive is issued by the MAC entity of the non-initiating side to indicate termination of the link to a 
neighbour node. 

Generation: 

This primitive is generated by the MAC sublayer when it receives an indication in a MSH-NCFG message. 

Effect of receipt: 

The receipt of the primitive is an indication to the CS that the link to the given neighbour node is down and 
cannot be used for data delivery. 

Semantics: 

MAC_TERMINATE_CONNECTION.indication 

{ 

CID, 



The CID is the Connection ID in Mesh as conveyed in the Generic MAC header. 



£75/ 



54 ETSI TS 102 178 VI. 1.1 (2003-11) 



6.3.6 MAC_D ATA. request 



Function: 

This primitive defines the transfer of data to the MAC entity from a convergence sublayer service access point. 

Generation: 

This primitive is generated by a convergence sublayer whenever an MAC SDU is to be transferred to a peer 
entity. 

Effect of receipt: 

The receipt of the primitive causes the MAC entity to process the MAC SDU through the MAC sublayer and 
pass the appropriately formatted PDUs to the PHY layer for transfer to the peer MAC sublayer entity, using 
the Node ID specified. 

Semantics: 

MAC_DATA.request 
{ 

CID, 

length, 
data, 
encryption flag 



The CID is the Connection ID in Mesh as conveyed in the Generic MAC header. 

The length parameter specifies the length of the MAC SDU in bytes. 

The data parameter specifies the MAC SDU as received by the local MAC entity. 

The priority/class parameter embedded in the CID specifies priority class of the MAC SDU. 

The reliability parameter embedded in the CID specifies maximum number of transmission attempts at each 

hnk. 

The drop precedence parameter embedded in the CID indicates relative MSDU dropping likelihood. 

The encryption flag specifies that the data sent over this link is to be encrypted, if ON. If OFF, then no 

encryption is used. 

6.3.7 MAC_D ATA. indication 

Function: 

This primitive defines the transfer of data from the MAC to the convergence sublayer. 

Generation: 

This primitive is generated whenever an MAC SDU is to be transferred to a peer convergence entity. 

Effect of receipt: 

The effect of receipt of this primitive by a convergence entity is dependent on the validity and content of the 
MAC SDU. 

Semantics: 

MAC_DATA.request 

{ 

CID 

length, 
data, 

reception status, 
encryption flag 



The CID is the Connection ID in Mesh as conveyed in the Generic MAC header. 

The length parameter specifies the length of the MAC SDU in bytes. 

The data parameter specifies the MAC SDU as received by the local MAC entity. 

The reception status parameter indicates transmission success or failure for those PDUs received via the 

MAC_DATA.indication. 
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6.3.8 MAC_FORWARDING_UPDATE.request 

Function: 

This primitive defines the transfer of the centralized scheduling configuration to the MAC entity from a 
convergence sublayer service access point in the mesh BS. 

Generation: 

This primitive is generated in the mesh BS whenever it has changed the schedule tree. 

Effect of receipt: 

The receipt of this primitive causes the MAC to generate a MSH-CSCF message with the given information. 
The message shall be distributed to all the nodes listed in the tree. 

Semantics: 

The parameters of the primitive are as follows: 

MAC_FORWARDING_UPDATE.request 

{ 

number of nodes, 

node parameters[number of nodes] 



The number of nodes parameter indicates number of nodes in the scheduling tree of this mesh BS. 
The node parameters entry shall contain the following information: 

Node ID: The Node ID parameter indicates the node. 

number of children: The number of nodes parameter indicates number of children the given node. 

child parameters [number of children] 

Each child parameters entry shall containing the following information: 

child index: The child index indicates index into the list of Node IDs 

uplink burst profile: The uplink burst profile indicates burst profile of link to child node 

downlink burst profile: The downlink burst profile indicates burst profile of link from child node. 

6.3.9 MAC_FORWARDING_UPDATE.indication 

Function: 

This primitive defines the transfer of the centralized scheduling configuration from the MAC to the 
convergence sublayer. 

Generation: 

This primitive is generated by the MAC sublayer at all the nodes, which have received the MSH-CSCF 
message, when new centralized schedule with revised schedule tree takes effect. 

Effect of receipt: 

The receipt of this primitive synchronizes the forwarder and MAC scheduler to routing changes. 

Semantics: 

MAC_FORWARDING_UPDATE.indication 

{ 

Node ID self 

number of nodes, 

node parameters [number of nodes] 
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The Node ID self indicates the Node ID of the node itself. 

The number of nodes parameter indicates number of nodes in the scheduling tree of this mesh BS. 

The node parameters entry shall contain the following information: 

Node ID: The Node ID parameter indicates the node. 

number of children: The number of nodes parameter indicates number of children the given node. 

child parameters [number of children] 

Each child parameters entry shall contain the following information: 

child index: The child index indicates index into the list of Node IDs 

uplink burst profile: The uplink burst profile indicates burst profile of link to child node 

downlink burst profile: The downlink burst profile indicates burst profile of link from child node. 

6.4 MAC management message applicability 

When implementing the mesh mode, all clauses referring to the mesh mode in the standard shall apply as mandatory. 
Basic functionalities are mandatory for a mesh node as they are for a PMP node, except those that are stated as optional 
below. 

For a mesh-enabled system, the messages below and the corresponding functionality are always mandatory to 
implement: 

MSH-NCFG 

MSH-NENT 

MSH-DSCH 

MSH-CSCH 

MSH-CSCF 

REG-REQ 

REG-RSP 

PKM-REQ 

PKM-RSP 

SBC-REQ 

SBC-RSP 

TFTP-CPLT 

TFTP-RSP 

RES-CMD 

For a mesh enabled system, the following messages and the corresponding functionality are mandatory/optional 
whenever they are correspondingly optional/mandatory for a PMP system: 

ARQ-Feedback 

AAS-FBCK-REQ 

AAS-FBCK-RSP 

When operating in the mesh mode, the messages below and the corresponding functionality are not used. 

DL-MAP 

DCD 

DSC-ACK 

DSC-REQ 

DSC-RSP 

DSD-RSP 

DSX-RVD 

UCD 

UL-MAP 

CLK-CMP 

DBPC-REQ 

DBPC-RSP 

DREG-CMD 

MCA-REQ 

MCA-RSP 

RNG-REQ 
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RNG-RSP 
DSA-ACK 
DSA-REQ 
DSA-RSP 



6.5 Network synchronization 



Network configuration (MSH-NCFG) and network entry (MSH-NENT) packets provide a basic level of communication 
between nodes in different nearby networks whether from the same or different equipment vendors or wireless 
operators. These packets are used to synchronize both centralized and distributed control mesh networks. 

This communication is used to support basic configuration activities such as: synchronization between nearby networks 
used (for instance, for multiple, co-located BSs to synchronize their uplink and downlink transmission periods), 
communication and coordination of channel usage by nearby networks, and discovery and basic network entry of new 
nodes. 

MSH-NCFG, MSH-NENT and MSH-DSCH can all assist a node in synchronizing to the start of frames. For these 
messages, the control subframe, which initiates each frame, is divided into transmit opportunities (see TS 102 177 [3]). 
The first transmit opportunity in a network control subframe may only contain MSH-NENT messages, while the 
remainder MSH_CTRL_LEN-1 may only contain MSH-NCFG messages. In scheduling control subframes, the 
MSH-DSCH_NUM transmit opportunities assigned for MSH-DSCH messages come last in the control subframe. The 
MSH-NCFG messages also contain the number of its transmit opportunity, which allows nodes to easily calculate the 
start time of the frame. 

6.5.1 Physical neighbour list 

All the basic functions like scheduling and network synchronization are based on the neighbour information all the 
nodes in the mesh network shall maintain. Each node (BS and SS) maintains a physical neighbourhood list with each 
entry containing the following fields: 

MAC Address 

48-bit MAC address of the neighbour. 

Hop Count 

Indicates distance in hops of this neighbour from the present node. If a packet has been success-fully received 
from this neighbour recently (defined further below), it is considered to be 1 hop away. 

Node Identifier 

16-bit Number used to identify this node in a more efficient way in MSH-NCFG messages. 

XmtHoldoffTime 

The minimum number of MSH-NCFG transmit opportunities that no MSH-NCFG message transmission is 
expected from this node after Next Xmt Time (see for detailed definition). 

Next Xmt Time 

The MSH-NCFG transmit opportunity(ies) in which the next MSH-NCFG from this node is expected (see for 
detailed definition). 

Reported Flag 

Set to TRUE if this Next Xmt Time has been reported by this node in a MSH-NCFG packet. Else set to 
FALSE. 

Synchronization hop count 

This counter is used to determine superiority between nodes when synchronizing the network. Nodes can be 
assigned as master time keepers, which are synchronized externally (for example using GPS). These nodes 
transmit Synchronization hop count of 0. Nodes shall synchronize to nodes with lower synchronization hop 
count, or if counts are the same, to the node with the lower Node ID. 

The Physical Neighbourhood List is updated as follows when a MSH-NCFG packet is received from a neighbour: 

The hop count field in the Physical Neighbourhood List for the neighbour itself is set to 1. The hop count field 
for other nodes listed in the MSH-NCFG message is set to Hops to Neighbour +2 (see table) unless they are 
already listed with a lower hop count. 
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The Next Xmt Time and Xmt Holdoff Time of the neighbour and all nodes listed in the MSH-NCFG are 

updated. 

The 'Reported Flag' for each entry in the Physical Neighbour table which was modified is set to FALSE. 



6.5.2 MSH-NCFG / MSH-NENT transmission cinannel and timing 

MSH-NCFG and MSH-NENT packets are scheduled for transmission during control subframes. So that all nearby 
nodes receive these transmissions, the channel used is cycled through the available channels in the band, with the 
channel selection being based on the Frame number. So, for Frame Number /, the channel is determined by the array 
lookup: 



NetConfigChannel = Logical channel list 



Frame Number 



Scheduling Frames x 4 + 1 



J mod Num_Channels 



(14) 



where the Logical channel List and Scheduling Frames are derived from the MSH-NCFG:Network Descriptor 
(see table 44). 



6.5.2.1 



MSH-NCFG next transmission scheduling 



During the current Xmt Time of a node (i.e. the time slot when a node transmits its MSH-NCFG packet), the node uses 
the following pseudo-code procedure to determine its Next Xmt Time: 

Order its physical neighbour list by Next Xmt Time. 

For each entry in the neighbour list; 

Entry's Earliest Subsequent Xmt Time = Entry's Next Xmt Time + Entry's Xmt Holdoff Time 

Success = FALSE; 

TempXmtTime = Xmt Time + Xmt Holdoff Time 

While (Success == FALSE) do { 

Determine the eligible competing nodes, which is the set of all nodes in the physical- 
neighbour list for which: 

TempXmtTime c Entry's Next Xmt Time eligibility interval (see Eq. 2) OR 
Entry's Earliest Subsequent Xmt Time < TempXmtTime. 



if ( MeshElection (TempXmtTime, MyNodelD, CompetingNodelDsList [ ] == FALSE) 
Set TempXmtTime equal to the next MSH-NCFG Xmt opportunity. 

else : 

Success = TRUE 

Next Xmt Time =TempXmtTime . 



The Mesh Election procedure determines whether the local node is the winner for a specific TempXmtTime among all 
the competing nodes. It returns TRUE if the local node wins or FALSE otherwise .The algorithm works as follows: 

boolean MeshElection (uint32 XmtTime, uintl6 MyNodelD, uintl6 NodelDList [ ] )) { 
uint32 nbr_smear_val, smear_vall, smear_val2; 
smear_vall =inline_smear (MyNodelD ^ XmtTime )); 
smear_val2 =inline_smear (MyNodelD IXmtTime ) ; 
For each Node ID nbrsNodelD in NodelDList Do { 

nbr_smear_val =inline„smear (nbrsNodelD ''' XmtTime ) ) ; 
if (nbr_smear_val >smear_vall ) ( 

return FALSE; //This node loses. 
} 

else if (nbr_smear_val ==smear_vall ) ( 
//1st tie-breaker. 

nbr_smear_val =inline_smear (nbrsNodelD IXmtTime ) ; 
if (nbr_smear_val >smear_val2 ) ( 

return FALSE; //This node loses. 
} 
else if (nbr_smear_val ==smear_val2 ) { 

//If we still collide at this point Break the tie based on MacAdr 
if ( (XmtTime is even && (nbrsNodelD >MyNodeID) ) 1 1 
(XmtTime is odd && (nbrsNodelD <MyNodeID ) ) ) { 
return FALSE; //This node looses. 
} 
} 
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//This node won over this competing node 
}//End for all competing nodes 
//This node is winner^ it won over all competing nodes. 
return TRUE; 
} 

// Convert a uniform 16-bit value to an uncorrelated uniform 16-bit hash value, uses mixing. 

uint32 inline_smear (uint 16 val) ( 

val += (val <<12) ; 

val ''= (val >>22) ; 

val += (val <<4) ; 

val ^= (val >>9) ; 

val += (val <<10) ; 

val ^= (val >>2) ; 

val += (val <<7) ; 

val ^= (val >>12) ; 

return (val) ; 
} 

6.5.2.2 MSH-NENT next transmission scheduling 

The NetEntry scheduling protocol provides the upper layer protocol an unreliable mechanism to access the NetEntry 
slot(s), so that new nodes, which are not yet fully-functional members of the network, can communicate with the 
fully-functional members of the network. 

In the NetEntry slots new nodes shall transmit MSH-NENT messages using the following two step procedure: 

1) The initial MSH-NENT packet with request IE is sent in a random, contention-based fashion in a free network 
entry transmission slot in the immediately following MSH-NENT transmission opportunity after the targeted 
sponsor sends a MSH-NCFG. with sponsored MAC address 0x000000000000. 

2) After the sponsor advertises the new nodes MAC Address in a MSH-NCFG message, the new node may send 
a MSH-NENT in the immediately following MSH-NENT transmission opportunity. 

A new node uses the algorithm specified by the following pseudocode to access NetEntry transmission slots: 

/♦Variable Definitions */ 

Pkt *MSH-NENT_MsgQ =NULL; //MSH-NENT Message queue 

uint SponsorsState =UNAVAILABLE; //SponsorsState and OthersState record the NetEntry 

uint OthersState =BUSY; 

// Address in the MSH-NCFG packet form the sponsor or other nodes, 

// which can be used to determine the availability of the next NetEntry transmission opportunity 

//SponsorsState can be UNAVAILABLE, AVAILABLE and POLLING. 

//OthersState can be AVAILABLE and BUSY. 

uint OthersMaxMacAdr =OxFFFFFFFF; 

uint OthersMinMacAdr =0x00000000; 

void RecvOutgoingMSH-NENT_Msg (Pkt *MSH-NENT_Msg) { 
MSH-NENT_MsgQ->enqueue (MSH-NENT_Msg) ; 

} 

void RecvIncomingMSH-NCFG_Msg (Pkt *MSH-NCFG_Msg) { 
if (MSH-NCFG_Msg->sourceMacAdr ==sponsorsMacAdr) { 
switch (MSH-NCFG_Msg->NetEntryAddress) 
{ 

case 0x000000000000: SponsorsState =AVAILABLE; break; 
case myMacAdr: SponsorsState =POLLING; break; 

default: break; 

} 
} else { 

switch (MSH-NCFG_Msg->NetEntryAddress) 
{ 

case OxOOOOOOOOOOOO:break; 
default: OthersState =BUSY; 

if (OthersMaxMacAdr <MSH-NCFG_Msg->NetEntryAddress) 

OtherMaxMacAdr=MSH-NCFG_Msg->NetEntryAddress; 
if (OthersMinMacAdr >MSH-NCFG_Msg->NetEntryAddress) 
OtherMinMacAdr =MSH-NCFG_Msg->NetEntryAddress; 
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void NetworkControlSubf rameStart ( ) { 
boolean xmt =FALSE; 
if (MSH-NENT_MsgQ->qLength ) { 

if (SponsorsState ==AVAILABLE) { 
if (OthersState !=BUSY) 

xmt =TRUE; 
} 
else if (SponsorsState ==POLLING) { 
if (OthersState !=BUSY) 

xmt =TRUE; 
else if ( ( (mayMacAdr >OthersMaxMacAdr) && (even supperframe) ) I I 
( (mayMacAdr <OthersMinMacAdr) && (odd supperframe))) 
xmt =TRUE; 



if (xmt) { 

Pkt*MSH-NENT_Msg =MSH-NENT_MsgQ->getHead ( ) 
MSH-NENT_MsgQ->dequeue (MSH-NENT_Msg) ; 
SendOutPkt (MSH-NENT_Msg, nextNetEntryslot ) 

} 

SponsorsState =UNAVAILABLE; 

OthersState =AVAILABLE; 

Other sMaxMacAdr =0x000000000000; 

Other sMinMacAdr =OxFFFFFFFFFFFF; 



The individual subroutines are triggered by the transmission of a MSH-NENT packet, the reception of a MSH-NCFG 
packet and the start of a NetworkControl Subframe respectively. 

6.6 Network entry and synchronization 

Node initialization and network entry procedures in mesh mode are in some aspects different from those in PMP mode. 
A new node entering the mesh network obeys the following procedures. The whole entry pro-cess to the stage when the 
node can start scheduled transmissions can be divided into the following phases: 

1) Scan for active network and establish coarse synchronization with the network. 

2) Obtain network parameters (from MSH-NCFG messages). 

3) Open Sponsor Channel. 

4) Node authorization. 

5) Perform registration. 

6) Establish IP connectivity. 

7) Establish time of day. 

8) Transfer operational parameters. 

Each node shall contain a 48-bit universal MAC address assigned during the manufacturing process. This is used to 
identify the node to the various provisioning servers during initialization and whenever performing authentication with 
a neighbour node. 

6.6.1 IVIAC management message tunnelling 

In Mesh networks during network entry certain MAC Message protocols take place between entities separated by 
multiple hops. In these cases the Sponsor Node shall relay the MAC Messages from the new node acting as the SS to 
the peer performing the duties of the PMP BS. The sponsor shall also relay the messages from the BS entity to the new 
node. 

The Sponsor shall tunnel the MAC Messages received from the New Node (SS) listed in table 65 over UDP as shown in 
figure 6. to the entity performing the BS part of the protocol. The UDP source and destination port used for tunnelled 
messages shall be equal to 80216_UDP_PORT. The sponsor shall also extract the MAC messages from the UDP 
packets arriving from the BS entity and transmit them over the air to the New Node. 
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Table 65: MAC management message tunnelling over UDP 



Message 


Sponsor action 


Direction of 
message 


PKM-REQ: Auth Request 


Tunnel 


SS to BS 


PKM-REQ: Auth Info 


Tunnel 


SS to BS 


PKM-REQ: Auth Reply 


Extract 


BS to SS 


PKM-REQ: Auth Reject 


Extract 


BS to SS 


REG-REQ 


Tunnel 


SS to BS 


REG-RSP 


Extract 


BS to SS 


DSA-REQ 


Tunnel 


SS to BS 


DSA-RSP 


Extract 


BS to SS 


DSA-ACK 


Tunnel 


SS to BS 



IP header(s) 


UDP header 


Tunnel Subheader 


Message including headers 



Figure 6: IVIAC management message tunnelling message format 

The format of the Tunnel Subheader is defined in table 66. 

Table 66: Tunnel Subheader format 



Syntax 


Size 


Notes 


Tunnel Subheader() { 






Type 


8 bits 


= Reserved 

1 = HIPERMAN MAC header 
2-255 = Reserved 


} 







Also, MAC messages may need to be tunnelled end to end in cases when the protocol takes place between peers 
separated by several hops. The packet format in figure 6 shall be used in these cases with the Tunnel Subheader format 
defined in table 66. 

6.6.2 Scanning and coarse synchronization to network 

On initialization or after signal loss, the node shall search for MSH-NCFG messages to acquire coarse synchronization 
with the network. Upon receiving a MSH-NCFG message the node acquires the network time from the Timestamp 
field. The node may have non-volatile storage in which all the last operational parameters are stored and shall first try to 
re-acquire coarse synchronization with the network. If this fails, it shall begin to continuously scan the possible 
channels of the frequency band of operation until a valid network is found. 

Once the PHY has achieved synchronization, the MAC Sublayer shall attempt to acquire network parameters. At the 
same time the node shall build a Physical Neighbour List (see clause 6.5.1). 
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Figure 7: Synchronization and networic entry - new node I 



6.6.3 Obtaining network parameters 



A node shall remain in synchronization as long as it receives MSH-NCFG messages. A node shall accumulate MSH- 
NCFG messages at least until it receives a MSH-NCFG message from the same node twice and until it has received a 
MSH-NCFG Network Descriptor with an operator ID matching (one of) its own if it has any. In parallel the new node 
shall update its Physical Neighbour List (see clause 6.5.1) from the acquired information. 

From the established physical neighbour list, the new node shall select a potential Sponsoring Node out of all nodes 
having the Logical Network ID of the node for which it found a suitable Operator ID. The new node then shall then 
synchronize its time to the potential sponsor assuming propagation delay after which it shall send a MSH-NENT 
NetEntryRequest including the Node ID of the potential sponsor. To determine a suitable transmission time, the node 
shall adhere to clause 6.5.2.2. 

Until the node has obtained a unique Node ID, it shall use temporary Node ID (0x0000) as Transmitter's Node ID in all 
transmissions. 

Once the Candidate Node has selected a Sponsoring Node, it shall use the Sponsoring Node to negotiate basic 
capabilities and to perform authorization. For that purpose the Candidate Node shall first request the Sponsoring Node 
to open Sponsor Channel for a more effective message exchange. 
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6.6.4 Opening sponsor channel 



Once the new node has selected one of its neighbours as the candidate Sponsoring Node it becomes a Candidate Node. 
To get further in the initialization procedure the Candidate Node shall request the candidate Sponsoring Node to 
establish a temporary schedule which could be used for further message delivery during the Candidate Node 
initialization. The temporary schedule requested is termed Sponsor Channel. 

The process is initiated by the Candidate Node which transmits a MSH-NENT NetEntryRequest message (a 
MSH-NENT message with Type set to 0x2) to the Sponsoring Node. 

Upon reception of the MSH-NENT NetEntryRequest message with the Sponsor Node ID equal to Node ID of its own, 
the candidate Sponsoring Node shall assess the request and either opens the Sponsor Channel or rejects the request. The 
response is given in a MSH-NCFG message with an Embedded Data as defined in clause 4.3.18.3. If the candidate 
Sponsoring Node does not advertise the Candidate Node's MAC address in the sponsor's next MSH-NCFG 
transmission, then the procedure is repeated MSH_SPONSOR_ATTEMPTS times using a random backoff between 
attempts. If these attempts all fail, then a different Candidate Sponsoring Node is selected and the procedure repeated 
(including re-initializing coarse network synchronization). If the selected candidate Sponsoring Node does advertise the 
Candidate Node's MAC address, it shall continue to advertise this MAC address in all its MSH-NCFG messages until 
the sponsorship is terminated. 

Once the Candidate Node has received a positive response (a NetEntryOpen message) in from the candidate Sponsoring 
Node in the MSH-NCFG message, it shall acknowledge the response by transmitting a MSH- NENT NetEntryAck 
message (a MSH-NENT message with Type set to 0x1) to the Sponsoring Node at the first following network entry 
transmission opportunity. Before that the Candidate Node shall perform fine time synchronization. It makes a correction 
to its transmission timing by the Estimated propagation delay indicated in the embedded MSH-NCFG NetEntryOpen 
message. 

If the Sponsoring Node accepted the request and opened a Sponsor Channel, the channel is ready for use immediately 
after the transmission of the acknowledgement message. At the same the candidate Sponsoring Node becomes the 
Sponsoring Node. 

If the candidate Sponsoring Node embedded a MSH-NCFG NetEntry Reject, the new node shall perform the following 
action based on the rejection code: 

0x0: Operator Authentication Value Invalid 

The Candidate Node shall select a new candidate Sponsoring Node with a different operator ID. 

0x1: Excess Propagation delay 

The Candidate Node shall repeat its MSH-NENT:NetEntryRequest in the following network entry 
transmission opportunity to the same candidate Sponsoring Node. 

0x2: Select new sponsor 

The Candidate Node shall select a new candidate Sponsoring Node. 

If the candidate Sponsoring Node embedded neither MSH-NCFG NetEntryOpen nor MSH-NCFG NetEntryReject, the 
Candidate Node shall wait (with timeout time T2), for the next MSH-NCFG with NetEntryOpen from the candidate 
Sponsoring Node and resend the MSH-NENT NetEntryRequest on timeout. 

The Candidate Node and the Sponsoring Node use the schedule indicated in the NetEntryOpen message to perform 
message exchanges described in clauses 6.6.5 through 6.6.10. After this is completed, the Candidate Node shall 
terminate the entry process by sending a MSH-NENT NetEntryClose message to the Sponsoring Node in the network 
entry transmission immediately following a MSH-NCFG transmission from the Sponsoring Node, which shall Ack 
termination with MSH-NCFG NetEntryAck. 
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Figure 8: Synchronization and networl^ entry - new node II 
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Table 67 displays the message transfer sequence during a successful network entry without repetitions or time-outs. 

Table 67: Network entry successful message exchange 



Sponsor node 








New node 


Nodes in network routinely advertise 
network with 
IVISH-NCFGiNetwork Descriptor 

[IVISH-NENT NetEntryRequest with own 

Node ID] 

Send NetEntryReject or NetEntryOpen 

with new node's MAC address and 

schedule allocation for higher layer 

authentication and configuration 

exchange 




MSH-NCFG: 




[detecting MSH-NCFG messages with 
Network Descriptor] 
Attempt to enter the network 

Send ACK to confirm schedule 


<— 


Network Descriptor 

MSH-NENT: 
~ NetEntryRequest 

MSH-NCFG: 




NetEntryOpen 
MSH-NENT: 






NetEntryAcK 




Security sublayer and basic capability exchange operations 


Acknowledge closure of sponsorship 

And drop new node's IVIAC address from 

subsequent MSH-NCFG messages 




MSH-NENT: 




After authentication and configuration, 
close entry procedure 

New node is now regular node in 
network 




NelEnlryClose 
MSH-NENT 






NetEntryAck 





6.6.5 Negotiating basic capabilities 

In Mesh Mode, basic capability negotiation is the same as for PMP systems and shall be performed after a logical link 
has been established. The node which requested the logical link shall act as the SS and initiate the SBC-REQ. 

6.6.6 Node Autinorization 

The new node shall perform authorization in an identical fashion as PMP systems. The new node shall act as the SS. 
The sponsor node upon reception of the Authent Info and Auth Request shall tunnel the messages as described in to the 
Authorization Node. The Authorization Node, acting as the BS, shall verify the SS Certificate of the new node and 
determine whether the new node is authorized to join the Network. Upon receiving tunnelled PKM-RSP MAC 
Messages from the Authorization Node the Sponsor shall forward the messages to the new node. 

6.6.7 Node Registration 

Registration is the process by which a node is assigned its Node ID. The sponsoring node upon reception of the 
REG-REQ shall tunnel the message as described in clause 6.6.1 to the Registration Node. Upon receiving tunnelled 
REG-RSP MAC Messages from the Registration Node the Sponsor shall forward the messages to the new node. The 
new node shall follow the procedure in figure 10. The Registration Node shall follow the procedure in figure 11. 
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Figure 10: Registration - candidate node 
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Figure 11: Registration - registration node 



6.6.8 Establishing IP connectivity 



The node shall acquire an IP address using DHCP in a fashion identical to PMP systems. However, the procedure shall 
take place over the Sponsor Channel. 
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6.6.9 Establishing time of day 



The node shall retrieve the time of day in a fashion identical to PMP. However, the messages shall be carried over UDP 
in the Sponsor Channel. 



6.6.1 Transfer of operational parameters 



After successfully acquiring an IP address via DHCP the node shall download a parameter file using TFTP in a fashion 
identical to PMP systems. However, the node shall use the Sponsor Channel instead of the Secondary Management 
connection. 

Upon receiving tunnelled REG-RSP MAC Messages from the Provisioning Node the Sponsor shall forward the 
messages to the Candidate Node. 

The following additional configuration file encodings are available: 



Name 


Type 


Length 


Value 


Authorization Node 


22 


4 or 16 


IP Address of tlie Autliorization Node 


Registration Node 


23 


4 or 16 


IP Address of the Registration Node 


Provisioning Node 


18 


4 or 16 


IP Address of the Provisioning Node 



Using mesh, QoS is provisioned on a packet-by-packet basis using the Mesh CID. The connection-based QoS 
provisioning using the DSx messages are hence not used. A node obtains its AuthorizedQoSParamSet during the 
transfer of operational parameters. 

6.7 Privacy sublayer 

The privacy sublayer for Mesh mode is identical to that of PMP mode with the following exceptions. 

6.7.1 TEK exchange overview 

Upon achieving authorization, a Node starts for each Neighbour a separate TEK state machine for each of the SAJDs 
identified in the Authorization Reply message. Each TEK state machine operating within the Node is responsible for 
managing the keying material associated with its respective SAID. The Node is responsible for maintaining the TEKs 
between itself and all nodes it initiates TEK exchange with. Its TEK state machines periodically send Key Request 
messages to the Neighbours of the node, requesting a refresh of keying material for their respective S AIDs. 

The Neighbour replies to a Key Request with a Key Reply message, containing the BS's active keying material for a 
specific SAID. 

The Traffic Encryption Key (TEK) in the Key Reply is encrypted, using the node's public key found in the 
SS-Certificate attribute. 

Note that at all times the node maintains two active sets of keying material per SAID per neighbour. The life-times of 
the two generations overlap such that each generation becomes active halfway through the life of its predecessor and 
expires halfway through the life of its successor. A neighbour includes in its Key Replies both of an SAID's active 
generations of keying material. 

The Key Reply provides the requesting Node, in addition to the TEK, the remaining lifetime of each of the two sets of 
keying material. The receiving Node uses these remaining lifetimes to estimate when the Neighbour invalidates a 
particular TEK, and therefore when to schedule future Key Requests. The transmit regime between the initiating Node 
and the Neighbour provides for seamless key transition. 

6.7.2 Node Re-Authorization 

When re-authorizing with the network, the re-authorizing node shall tunnel the authorization messages as shown in 
figure 6 over UDP. 
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6.7.3 TEK usage 

For each of its SAIDs, the neighbour shall transition between active TEKs according to the following rules: 

• At expiration of the older TEK, the neighbour shall immediately transition to using the newer TEK for 
encryption. 

• The neighbour that generated the TEK shall use the older of the two active TEKs for encrypting traffic towards 
the Node that initiated the TEK. 

• The neighbour that generated the TEK shall be able to decrypt traffic from each node using either the older or 
newer TEK. 

For each of its authorized SAIDs, the initiator node shall use the newer of its two TEKs to encrypt traffic towards its 
neighbours with which it initiated a TEK exchange, and shall be able to decrypt traffic from the neighbour's traffic 
encrypted with either of the TEKs. 

6.7.4 Usage of operator shared key 

Each node shall be capable of maintaining two active Operator Shared Secrets. A node shall use the Operator Shared 
Secret to calculate a HMAC digest for the Key Request and Key Reply messages when exchanging TEKs with its 
neighbouring nodes. 

6.7.5 HMAC authentication l^eys and calculation of HMAC digests 

The HMAC_KEY_S shall be derived as follows: 

HMAC_KEY_S = SHA(H_PAD_D I Operator Shared Secret) (15) 

where H_PAD_D = Ox3A repeated 64 times. 

HMAC digests calculated with the key HMAC_KEY_S shall be supported. When calculating the digest with this key 
the HMAC sequence Number in the HMAC tuple shall be equal to the Operator Shared Secret Sequence Number. 



6.8 Data scheduling 



Unlike the PMP mode, there are no clearly separate downlink and uplink subframes in the mesh mode. Each station is 
able to create direct communication links to a number of other stations in the network instead of communicating only 
with a BS. However, in typical installations, there will still be certain nodes which provide the BS function of 
connecting the mesh network to the backhaul links. In fact, when using mesh centralized scheduling (described below), 
these BS nodes perform much of the same basic functions as does the BS in PMP mode. Thus, the key difference is that 
in mesh mode all the SSs may have a direct links with other SSs. Further, there is no need to have direct link from a SS 
to the BS of the mesh network. This connection can be provided via other SSs. Communication in all these links shall 
be controlled by a centralized algorithm (either by the BS or 'decentralized' by all nodes periodically), scheduled in a 
distributed manner within each node's extended neighbourhood, or scheduled using a combination of these. 



6.8.1 Distributed scheduling 



The stations with which a station has direct links are called neighbours and shall form a neighbourhood. A node's 
neighbours are considered to be 'one hop' away from the node. A two-hop extended neighbourhood contains, 
additionally, all the neighbours of the neighbourhood. In the coordinated distributed scheduling mode, all the stations 
(BS and SSs) shall coordinate their transmissions in their extended two-hop neighbour-hood. 

The coordinated distributed scheduling mode uses some or the entire control portion of each frame to regularly transmit 
its own schedule and proposed schedule changes on a PMP basis to all its neighbours. Within a given channel all 
neighbour stations receive the same schedule transmissions. All the stations in a network shall use this same channel to 
transmit schedule information in a format of specific resource requests and grants. 

Coordinated distributed scheduling ensures that transmissions are scheduled in a manner that does not rely on the 
operation of a BS, and that are not necessarily directed to or from the BS. 
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Within the constraints of the coordinated schedules (distributed or centraHzed), uncoordinated distributed scheduHng 
can be used for fast, ad-hoc setup of schedules on a link-by-link basis. Uncoordinated distributed schedules are 
established by directed requests and grants between two nodes, and shall be scheduled to ensure that the resulting data 
transmissions (and the request and grant packets themselves) do not cause collisions with the data and control traffic 
scheduled by the coordinated distributed nor the centralized scheduling methods. 

Both the coordinated and uncoordinated distributed scheduling employ a three-way handshake. 

1) A MSH-DSCH:Request is made along with MSH-DSCH:Availabilities, which indicate potential slots for 
replies and actual schedule. 

2) A MSH-DSCH:Grant is sent in response indicating a subset of the suggested availabilities which fits, if 
possible, the request. The neighbours of this node not involved in this schedule shall assume the transmission 
takes place as granted. 

3) A MSH-DSCH:Grant is sent by the original requester containing a copy of the grant from the other party, to 
confirm the schedule to the other party. The neighbours of this node not involved in this schedule shall assume 
the transmission takes place as granted. 

The differences between coordinated and uncoordinated distributed scheduling is, that in the coordinated case, the 
MSH-DSCH messages are scheduled themselves in the control subframe in a collision free manner, whereas in the 
uncoordinated case, MSH-DSCH messages may collide. Nodes responding to a Request should, in the uncoordinated 
case, wait a sufficient number of minislots of the indicated Availabilities before responding with a grant, such that 
nodes listed earlier in the Request have an opportunity to respond. The Grant confirmation is sent in the minislots 
immediately following the first successful reception of an associated Grant packet. 

The relevance of the MSH-DSCH is solely defined by the message itself and entirely up to the station transmitting it. 



6.8.2 Centralized scheduling 



The schedule using centralized scheduling is determined in a more centralized manner than in the distributed scheduling 
mode. 

The network connections and topology are the same as in the distributed scheduling mode described in , but some 
portion of the scheduled transmissions for the SSs less than or equal to HOPRANGE_THRESHOLD hops from the BS 
shall be either defined by the BS or computed by the SSs themselves. HOPRANGE_THRESHOLD, may be determined 
at the system start up phase or may be dynamic according to considerations such as network density, the proximity of 
other BSs, and/or the dynamic characteristics of the traffic streams. 

In the basic form, the BS shall provide the schedule for all the SSs less than or equal to HOPRANGE_THRESHOLD 
hops from the BS. The BS determines the flow assignments from the resource requests from the SSs within the 
HOPRANGE_THRESHOLD hop range. Subsequently, the SSs themselves determine the actual schedule from these 
flow assignments by using a common algorithm that divides the frame proportionally to the assignments. Thus the BS 
acts just like the BS in a PMP network except that not all the SSs have to be directly connected to the BS and the 
assignments determined by the BS extends also to those SSs not directly connected to the BS but less than 
HOPRANGE_THRESHOLD hops from it. The SS resource requests and the BS assignments are both transmitted 
during the control portion of the frame. 

Centralized scheduling ensures that transmissions are coordinated to ensure collision-free scheduling over the links in 
the routing tree to and from the BS, typically in a more optimal manner than the distributed scheduling method for 
traffic streams (or collections of traffic streams which share links) which persist over a duration that is greater than the 
cycle time to relay the new resource requests and distribute the updated schedule. 

A simple example of the use of the centralized scheduling flow-mechanism in MSH-CSCH is provided. For the network 
in figure 12, the requested flows are shown. For simplicity of notation, the data rate is assumed to be the burst profile 
number. 

The link fractions shown in figure 13 are multiplied with 2^^°^^'^^^'^ Exponent+14 ^^^^ table 55) and with the Frame 
Duration, then rounded up to the nearest duration of a whole number of minislots required to transmit this fraction 
(including preamble). 
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Figure 12: MSH-CSCF schedule example 
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Figure 13: MSH-CSCH flow usage example 

The number of frames over which the CSCH schedule is valid is limited by the number of frames it takes to aggregate 
and distribute the next schedule. 

Each node uses the newly received schedule to compute its retransmission time (if eligible) and the last frame when a 
node will be receiving this schedule, as well as the time when the mesh BS sent it. To compute this, the node uses the 
routing tree from the last MSH-CSCF messages as modified by the link updates of the last MSH-CSCH message (which 
dictates the size of MSH-CSCH messages) and the following rules; 

The mesh BS transmits first in a new frame. 

Then, the eligible children of the mesh BS (i.e. nodes with hop count equal 1), ordered by their appearance in 
the routing tree, transmit. 

Then, the eligible children of the nodes from step 2 (i.e. nodes with hop count equal 2), also ordered by their 
appearance in the routing tree, transmit. 

. . .continue until all eligible nodes in the routing tree have transmitted. 

Nodes shall fragment their message if it does not fit entirely before the end of the control subframe and at least 
the preamble and one data symbol fit. 

All nodes are eligible to transmit the grant schedule, except those that have no children. 
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• If a node's order requires it to transmit immediately after receiving, a delay of MinCSForwardingDelay ^.s is 
inserted. 

Each node shall also compute the timing of the uplink requests. Uplink requests start in the last frame in which a node 
received the previous schedule. All nodes are eligible to transmit requests, except the mesh BS. The request 
transmission order is reverse in hopcount (i.e. largest hopcount first), but retains the transmission order as listed in the 
routing tree for nodes with the same hopcount. 

The number of frames over which the CSCH schedule is valid is limited by the number of frames it takes to aggregate 
and distribute the next schedule. The time between the first frame in which a node sends the request schedule and the 
last frame in which a node receives the new grant schedule marks the validity of the previous grant schedule 
(see figure 14). This validity time overrides the Frame schedule flag two frame usage at the end of the validity time. 
Note that MSH-CSCF messages may be sent after the last request is received and before the grant schedule is 
transmitted by the mesh BS. 

Validity of previous schedule 



Tree 
depth 



MinCSForwardDelay 



Control subframe 



Data subframe 



Figure 14: MSH-CSCH schedule validity 



Adaptive antenna system support 



The use of adaptive antenna arrays can improve range and system capacity, by adapting the joint antenna pattern and 
concentrating its radiation to each individual subscriber. The spectral efficiency can be increased linearly with the 
number of antenna elements. This is achieved by steering beams to multiple users simultaneously so as to realize an 
inter-cell frequency reuse of one and an in-cell reuse factor proportional to the number of antenna elements. An 
additional benefit is the SNR gain realized by coherently combining multiple signals, and the ability to direct this gain 
to particular users. Another possible benefit is the reduction in interference achieved by steering nulls in the direction of 
co-channel interferers. 

Support mechanisms for AAS are specified, which allow a system to deliver the benefits of adaptive arrays while 
maintaining compatibility for non-AAS SSs. 

The design of the AAS option provides a mechanism to migrate from a non-AAS system to an AAS enabled system, in 
which the initial replacement of the non-AAS capable BS by an AAS capable BS should cause the only service 
interruption to (non-AAS) SSs. 

This is achieved by dedicating part of the frame to non-AAS traffic and part to AAS traffic. The allocation is performed 
dynamically by the BS. Non-AAS SSs shall ignore AAS traffic, which they can identify based on the 
DL-MAP/UL-MAP messages. AAS enabled SSs use dedicated private DL-MAP/ UL-MAP messages and are therefore 
prevented from colliding with non-AAS traffic. 

Special considerations apply to those parts of the frame that are not scheduled, e.g. initial-ranging and BW-request, as 
discussed in clauses 7.3 and 7.5. 



7.1 



DLC control functions 



The control of AAS part of the frame shall be done by unicasting private management messages to individual SSs. 
These messages (DL-MAP, UL-MAP, DCD, UCD and CLK-CMP) shall be the same as the broadcast MAC 
Management messages, except that the basic CID assigned to the SS is used instead of the Broadcast CID. 
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7.2 DL synchronization 



When the SS first attempts to synchronize to the DL transmission, the BS is unaware of its presence, and therefore is 
not aiming the adaptive array at its direction. Nevertheless, the frame preamble defined in TS 102 177 [3] is a repetitive 
well-known pattern, and SS may utilize the inherent processing gain associated with it in order to synchronize timing 
and frequency parameters with the BS. 



7.3 Initial ranging 



In an AAS system, a SS may be able to obtain the DL parameters if it receives the broadcast channel with enough 
energy so it can decode the DL-MAP and DCD messages. If this is the case, the SS can continue with the network entry 
process just like the non-AAS case, and the BS will get the chance to tune the adaptive array to it during the ranging 
process. Alternatively, an AAS SS may use the following procedure to alert the BS to its presence, so the BS can adapt 
its antenna array to the SS position. 

For AAS SS that are not able to initially decode the broadcast messages, a procedure is defined for them to alert the BS 
to their presence, so the BS can adapt the adaptive array to their position. 

An AAS-enabled BS may reserve initial-ranging contention slots for this alert procedure. The number of contention 
slots and their location in the frame is defined in clause 8.2 of TS 102 177 [3]. These contention slots shall be called 
AAS -alert-slots. 

AAS-enabled SSs not capable of decoding the DL broadcast messages shall use all available contention slots for initial 
ranging, in order to allow the BS adaptive array enough time and processing gain to shape the beam for it. After such an 
attempt the SS shall wait for a private DL-MAP and private DCD messages from the BS, and shall continue the network 
entry process like a non-AAS SS. If the private DL-MAP and DCD messages fail to arrive, the SS shall use an 
exponential backoff algorithm for selecting the next frame in which to attempt alerting the BS to its presence. 

7.4 Channel state information 

Adaptive array systems require channel state information. This information can be derived by relying on reciprocity of 
the channel or by using feedback messages. An AAS BS may use either method with TDD duplexing, and shall use the 
feedback messages with FDD duplexing. A SS shall be capable of provisioning feedback responses. 

The feedback method shall use two MAC control messages: AAS-FBCK-REQ and AAS-FBCK-RSP. The request 
instructs the SS to measure, the results of which shall be returned in the response after the measurement period has 
ended. The BS shall provide an UL allocation to enable the SS to transmit this response. 



7.5 Bandwidth requests 



AAS subscribers might not be able to request bandwidth using the usual contention mechanism. This happens because 
the BS's adaptive array may not have a beam directed at the SS when it is requesting BW, and the BW request will be 
lost. In order to avoid this situation, an AAS SS is directed by the BS as to whether or not it may use broadcast 
allocations for requesting bandwidth. The BS may change its direction dynamically using a TLV called 
ALLOW_BCAST_REQ, which is carried by the RNG-RSP message. The SS shall signify by using the 
CAN_RCV_BCAST TLV in the RNG_REQ message whether or not it can receive the broadcast messages. 

When a SS is directed not to use the broadcast CID to request bandwidth, it is the responsibility of the BS to provide a 
polling mechanism to learn about the SS bandwidth requirements. 

Note that AAS-enabled BSs are capable of receiving polled bandwidth requests from multiple AAS-enabled SS 
simultaneous, because multiple beams can be simultaneously formed. 
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8 Ranging 



The following specification shall apply instead of clause 6.2.10 in IEEE P802. 16-2001 [1]. However, the DL burst 
profile management clause 6.2.10.1 remains applicable. Clauses 8.1 and 8.2 also supplement clause 6.2.95 in 
IEEE P802. 16-2001 [1]. 



8.1 Initial ranging 

The SS shall calculate the maximum transmit signal strength for initial ranging from: 

PtX_IR_MAX = '^^^-*^^IR,max+ ^^EIRP ~ ^^^^ 

where the EIRxPjg^ ^.^^ and BS_EIRP are obtained from the DCD and RSS is the measured RSSI, by the SS. 



(16) 



Note that EIRxPj^ ^.^^ is the maximum equivalent isotropic received power, which is computed for a simple single- 
antenna receiver as RSS jj^ ^.^^ - G^f^-p gg j^^ , where the RSS jj^ ^.^^ is the received signal strength at the antenna input 
and G^j^j gg j^^ is the receive antenna gain. The BSgjj^p is the equivalent isotropic radiated power of the base station, 
which is computed for a simple single-antenna transmitter as Pj^ + Gant BS Tx' where Pj^ is the transmit power and 
^ANT BS Tx ^^ ^^^ transmit antenna gain. 

The SS shall send the RNG-REQ at a power level below Pjj^ jj^ MAX' measured at the antenna connector. 

If the SS does not receive a response, it shall resend it at the next Initial Maintenance transmission opportunity at one 
step higher power level. If the SS receives a response that contains the frame number in which the RNG-REQ was 
transmitted, but does not contain its Mac Address, it shall consider the transmission attempt unsuccessful but implement 
the corrections specified in the RNG-RSP and issue another RNG-REQ message after the appropriate back-off delay. If 
the SS receives a response containing its MAC Address, is shall consider the RNG-RSP reception successful. 

SSs which compute their Pj-^ jj^ ^.^ to exceed their maximum power level and SSs which have attempted initial 
ranging with the maximum power level using RNG-REQ may, if the BS supports sub-channelization, attempt 
sub-channelized initial ranging (see TS 102 177 [3]). 

When the BS detects a transmission in the ranging slot that it is unable to decode (including sub-channelized 
transmissions, it may respond by transmitting a RNG-RSP that includes transmission parameters but identifies the 
Frame Number and Initial Ranging Opportunity Number when the transmission was received instead of the MAC 
Address of the transmitting SS. 



'iNfaiting for N. 

RNG-REQ in Initial] 
Maintenance slot / 



See IEEE P802. 16-2001 



RNG-RSP 



RNG-RSP with 

Frame Number, 

Initial Ranging 

Opportunity Number/ 



Done 



Figure 15: Initial ranging - BS 
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Table 68: Ranging and automatic adjustment procedure 



Sponsor node 



New node 



[Time to send the Initial IVIaintenance 

interval] 

Send map containing Initial Maintenance 

IE with a broadcast CID. 



[Detect un-decodable RNG-REQ] 
Send response including Frame 
Number, Initial Ranging Opportunity 
Number, CID = 0. 



[Time to send the Initial IVIaintenance 

interval] 

Send map containing Initial Maintenance 

IE with a broadcast CID. 



[Detect decodable RNG-REQ] 
Allocate Basic and Primary Management 
CID and add Basic CID to poll list. 
Send response including SS MAC 
Address, Basic CID 



[time to send next map] 

send map with Station Management IE 

to SS using Basic CID 



Send ranging response 

Send periodic transmit opportunity to 
broadcast address 



-UL-MAP - 
RNG-REQ 

-RNG-RSP 



-UL-MAP - 
RNG-REQ 



-RNG-RSP 



-UL-MAP 



-RNG-REQ 
-RNG-RSP 



-UL-MAP 



Transmit ranging packet in contention 
mode with CID = 0. 



[Recognize Frame Number/ Opportunity 
when RNG-REQ was send] 
Adjust parameters according to RNG- 
RSP. 



Transmit ranging packet in contention 
mode with CID = 0. 



[Recognize own MAC Address] 

Store Basic CID and adjust parameters 

according to RNG-RSP. 



[Recognize own Basic CID] 

reply to Station Management opportunity 

poll. 

Adjust local parameters. 



8.2 Periodic ranging 



Two different ranging procedures shall be supported: initial ranging and periodic ranging. Initial ranging, which is 
described as part of the network entry and initialization process, serves to allow a new SS to acquire correct 
transmission parameters, such as time offset and Tx power level, so that the new SS can communicate with the BS 
properly. Periodic ranging serves to allow SSs to adjust transmission parameters during normal operations so that the 
SSs can communicate with the BS properly. Diagrams for periodic ranging are shown in figures 16, 17 and 18. 

The following summarizes the periodic ranging: 

1) Both the BS and the SSs shall use a timer T4 for periodic ranging and set the Initial Ranging timer T3 after a 
RNG-REQ message has been sent. 

2) The periodic ranging shall be conducted periodically at an interval sufficiently shorter than T4 that a map 
could be missed without the SS timing out. Any allocation to an SS constitutes a periodic ranging opportunity. 

3) A periodic ranging procedure can be originated by either the BS or the SSs. 

The BS can originate a periodic ranging procedure by sending an unsolicited RNG-RSP with adjustments 
based on any UL transmission it received from the SS. 
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ASS can originate a periodic ranging procedure by sending a RNG-REQ message in an allocation of UL 
bandwidth or a contention-based initial ranging slot. Upon receiving this RNG-REQ message, the BS 
shall send a RNG-RSP to the SS. 

4) Upon receiving a RNG-RSP message, the SS shall adjust the indicated transmission parameters accordingly 
and clear timer T3. 

5) The SS shall re-initialize its MAC sublayer (and re-register) when T3 expires and the number of RNG-REQ 
retries has been exceeded and when the Ranging Status indicates Abort. 



-^ Periodic Ranging 
BS 



On periodic timer. 

Ensure SS has UL 

allocation 



Map shall be sent per allocation algorithm 
and pending-until-complete . 

If RNG-REQ pending-until-complete was non- 
zero, the BS should hold off the station 
maitenance opportunity accordingly, unless 
needed (for example to adjust the SS's 
power level) . 




Destroy CIDs 

Associated with 

This SS 



Figure 16: Periodic ranging - BS 
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-^ Wait for RNG-REQ W- 



RNG-RSP with 
Status = Continue 



Delete SS from 
Poll list 



Destroy CIDs 

Associated with 

This SS 




RNG-RSP with 
Status = Success 



Periodic Ranging 
BS 



Done 



Figure 17: Periodic ranging - BS: Waiting for RNG-REQ 
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station 
Maintenance 
opportunity 




Reset T4 



UL data 



Error : N 
Re-initialize MAC ) 



Success or 
Continue 



Adjust parameters 

Per 

RNG-RSP 



RNG-REQ with 
anomalities 



Continue 



RNG-REQ 




Set T3 
(if not set) 



Operational 



Figure 18: Periodic ranging - SS 



9 Bandwidth allocation and request mechanism 

A compliant device shall not support the GPC mode as defined in IEEE P802. 16-2001 [1]. 

9.1 Contention-based BW requests for OFDM PHY 

The OFDM PHY supports two contention-based BW request mechanisms. The mandatory mechanism allows the SS to 
send the Bandwidth Request Header as specified in IEEE P802. 16-2001 [1] during a REQ Region-Full. 

Alternatively, the SS may send a Focused Contention Transmission during a REQ Region-Focused. This transmission 
uses the Focused Contention transmission, described in clause 7.3.3. One of the codes in table 12 will be randomly 
selected. The signal will be transmitted on a randomly selected TO, within time-frequency defined focused contention 
transmission window. 
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Upon detection, the BS shall provide a UL allocation for the SS to transmit a BW request MAC PDU, but instead of 
indicating a Basic CID, the broadcast CID shall be sent in combination with an OFDM Focused_Contention_IE, which 
specifies the Contention Channel, Contention Code and Transmit Opportunity which were used by the SS. This allows a 
SS to determine whether it has been given an allocation by matching these parameters with the parameters it used. In 
addition to the BW request header, the SS may send data as well. 

If the BS does not issue the UL allocation described above, or the BW request MAC PDU does not result in a 
subsequent allocation of any bandwidth, the SS shall assume that the Focused Contention Transmission resulted in a 
collision and follow the contention resolution as specified in clause 6.2.8 of IEEE P802. 16-2001 [1]. 



10 other 

10.1 Service definition: Usage of 
l\/IAC_create_connection. request for multicast 

This clause supplements clause 6.1.1.1 of IEEE P802. 16-2001 [1]. 

For a downlink multicast service, a MAC_CREATE_CONNECTION.request is issued by the CS at the BS for each SS 
that is associated with the service. An individual request contains the MAC Address of the SS to which the connection 
establishment is directed. It is stimulated by either the entry of the SS into the system or the provisioning of the service 
flow if this happens after the SS enters the system. 

After the BS MAC receives such a request, it establishes a DL MAC connection with the SS via a DSA-REQ message, 
using the CID associated with the multicast connection. All SSs involved in a multicast connection shall process the 
data transmitted on the connection with the given CID. Since a multicast connection is associated with a Service Flow, 
it is associated with the QoS and traffic parameters for that service flow. ARQ shall not be used on multicast 
connections. 

If a DL multicast connection is to be encrypted, each SS participating in the connection shall have an additional S A, 
allowing that connection to be encrypted using keys that are independent of those used for other encrypted 
transmissions between the SSs and the BS. 

10.2 Fragmentation 

This clause supplements clause 6.1.1.1 of IEEE P802. 16-2001 [1]. 

The maximum size of a fragment may be negotiated during or after connection establishment. When a maximum value 
has been established, the transmitter shall only form fragments whose length is less than or equal to this value even if 
the pending bandwidth allocation would accept a larger fragment. 

This value of the MAX_FRAGMENT_LENGTH TLV specifies the maximum size fragment a transmitter shall ever 
form or a receiver shall ever expect to receive. Valid values are 32 bytes to 2 041 bytes. A value of zero indicates no 
restriction. It is established by negotiation during the connection creation and connection change dialogs. The requester 
includes its desired setting in the REQ message. The receiver of the REQ message shall take the smaller of the value it 
prefers and value in the REQ message. This minimum value is included in the RSP message and becomes the agreed 
upon length value. Absence of the parameter during a DS A dialog shall indicate the originator of the message desires 
the maximum value. Absence of the parameter during a DSC dialog indicates the current setting shall remain in force. 

Table 69: Maximum fragment length TLV 



Name 


Type 


Length 


Value 


Scope 


MAX_FRAGMENT_LENGTH 


[24/25J.23 


2 


0-31 Reserved 

32-2 040 Maximum length in bytes 


DSA-REQ 
DSA-RSP 
DSC-REQ 
DSC-RSP 
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10.3 Map relevance and synchronization 

This clause supplements clause 6.2.7.6.1 of IEEE P802. 16-2001 [1]. 

All the timing information in the DL-MAP and UL-MAP is relative. The following time instants are used as a reference 
for the timing information 

• DL-MAP: the start of the first symbol (including the pre-amble if present) of the burst where the message is 
transmitted. 

• UL-MAP: the start of the first symbol (including the pre-amble if present) of the burst where the message is 
transmitted + Allocation Start Time value. 

The Maximum Map Pending shall be the end of the subsequent frame. 

10.4 CID allocations 

There are several CIDs defined in table 70 that have specific meaning. These identifiers shall not be used for any other 
purposes. 

Table 70: CID allocations 



CID 


Value 


Description 


Initial Ranging 


0x0000 


Used by an SS during initial ranging as 
part of initial ranging process. 


Basic 


0x0001 -m 




Primary IVIanagement 


m+^-2m 




Transport and 
Secondary IVIanagement 


2/n+y-OxFEFE 




AAS Initial Ranging 


OxFEFF 




IVIulticast Polling 


OxFFOO-OxFFFD 


An SS may be included in one or more 
multicast groups for the purposes of 
obtaining bandwidth via polling. These 
connections have no associated 
Service Flow. 


Padding 


OxFFFE 


Used for transmission of padding 
information. 


Broadcast 


OxFFFF 


Used for broadcast information that is 
transmitted on a DL to all SS. 



1 0.5 Configuration file encodings - TEK encryption identifiers 

The following TEK encryption algorithm identifiers are defined. 

Table 71 : TEK encryption algorithm identifiers 



Value 


Description 





Reserved 


1 


3-DESEDEwith 128-bit key 


2 


RSA with 1 024 bit key 


3-255 


Reserved 
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10.6 Global values 

This clause supplements clause 10.1 of IEEE P802. 16-2001 [1]. Systems shall meet the additional timing requirements 
contained in table 72. 

Table 72: Global values 



System 


Name 


Time reference 


min 


Default 


Max 


BS 


Max. Map Pending 


Maximum validity of map. 






End next 
frame 


BS,SS 


SS DL management 
message processing 
time 


Max. time between transmission of 
management message by BS and 
compliance to its instructions by SS. 






200 MS 


BS 


SBC Request retries 




3 


3 


16 


BS 


TFTP-CPLT retries 




3 


3 


16 


SS, BS 


122 


Wait for ARQ-Reset. 






0,5 s 


SS 


123 


Wait for TFTP-RSP. 






0,5 s 


Mesh node 


124 


Network Entry: Detect network. 


1 s 






Mesh node 


125 


Network Entry: Accumulate MSH-NCFG 
messages. 




120 s 




Mesh node 


126 


Network Entry: Wait for MSH-NENT / 
MSH-NCFG. 




1 s 





10.7 Additional encodings 
10.7.1 DLC version encodings 

The value of this field specifies a list of matching values for the IPv6 Flow label field. As the flow label field has a 
length of 20 bits, the first 4 bits of the most significant byte shall be set to 0x0 and disregarded. 

Table 73: DLC version encoding TLV 



Name 


Type 


Length 


Value 


Scope 


DLC version 


16 


1 


Version of the DLC supported on this channel. 
The current version is 1. 


REG-REQ 
REG-RSP 
DCD 



10.7.2 Additional packet classification rules 

Table 74: IPv6 flow label 



Name 


Type 


Length 


Value 


IPv6 Flow Label 


[24/25]. 100.9.14 


nx3 


Flow Label 1 ... Flow label n 
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